[AutoQA] #128: pst: Create a mechanism to ensure test clients are fully up-to-date

[fedora-badges]

#128: pst: Create a mechanism to ensure test clients are fully up-to-date
--------------------+-------------------------------------------------------
 Reporter:  kparal  |       Owner:                      
     Type:  task    |      Status:  new                 
 Priority:  major   |   Milestone:  Package Sanity Tests
Component:  tests   |     Version:  1.0                 
 Keywords:  tps     |  
--------------------+-------------------------------------------------------
 For sanity tests we will need that the test client machines are always
 fully up-to-date. We must think about a mechanism that will provide that
 for us.

 Will we have some kind of periodic task that will connect to all clients
 and update them? Or should the TPS test itself ensure the machine is up-
 to-date and only after that start executing itself?

 What about reboot? How do we know when it is necessary to reboot after an
 update? Will we reboot after each update, just to be sure nothing got
 broken?

-- 
Ticket URL: <https://fedorahosted.org/autoqa/ticket/128>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project

[fedora-badges]

#128: pst: Create a mechanism to ensure test clients are fully up-to-date
---------------------+------------------------------------------------------
  Reporter:  kparal  |       Owner:                      
      Type:  task    |      Status:  new                 
  Priority:  major   |   Milestone:  Package Sanity Tests
 Component:  tests   |     Version:  1.0                 
Resolution:          |    Keywords:  tps                 
---------------------+------------------------------------------------------
Comment (by kparal):

 skvidal came to help us in this noble quest, thank you!

 skvidal: you need something on your test systems to tell you if they are
 current and if they need a reboot?[[BR]]
 skvidal: updated is easy - you can do it in a few lines of python using
 yum - - in need of a reboot is also do-able - by checking rhe running
 kernel vs the latest installed kernel and then running needs-
 restarting[[BR]]
 kparal: may also some other components apart from kernel require
 restart?[[BR]]
 skvidal: yes - which is what needs-restarting is a about[[BR]]
 skvidal: it tells you which programs that are currently running are NOT
 running the latest version installed[[BR]]
 kparal: and that is a method inside yum API?[[BR]]
 skvidal: yes, in fact it is, now[[BR]]
 kparal: that's absolutely cool, thank you[[BR]]
 skvidal: well - to be fair - its a combination of a couple of functions in
 yum's api[[BR]]
 skvidal: check out http://yum.baseurl.org/gitweb?p=yum-utils.git;a=blob;f
 =needs-restarting.py;h=2c419486b2724896dc38625761f108499c17e1d1;hb=HEAD
 [[BR]]
 skvidal: the functions you need are

http://yum.baseurl.org/gitweb?p=yum.git;a=blob;f=yum/misc.py;h=66b0653583...

-- 
Ticket URL: <https://fedorahosted.org/autoqa/ticket/128#comment:1>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project

[fedora-badges]

#128: pst: Create a mechanism to ensure test clients are fully up-to-date
---------------------+------------------------------------------------------
  Reporter:  kparal  |       Owner:                      
      Type:  task    |      Status:  new                 
  Priority:  major   |   Milestone:  Package Sanity Tests
 Component:  tests   |     Version:  1.0                 
Resolution:          |    Keywords:  tps                 
---------------------+------------------------------------------------------
Comment (by skvidal):

 here's a simple script-yish way:

 yum check-update
 if the return code from that == 100 then you have updates available
 run yum update
 check the running kernel version (uname -r) compared to highest installed
 kernel version:
 http://sethdot.org/~skvidal/misc/highversion.py

 if they don't match then bounce the box

 If they do match then run needs-restarting from yum-utils.

 if it outputs ANYTHING then either:
 1. restart those apps
 or
 2. bounce the box.

-- 
Ticket URL: <https://fedorahosted.org/autoqa/ticket/128#comment:2>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project

[fedora-badges]

#128: pst: Create a mechanism to ensure test clients are fully up-to-date
---------------------+------------------------------------------------------
  Reporter:  kparal  |       Owner:                      
      Type:  task    |      Status:  new                 
  Priority:  major   |   Milestone:  Package Sanity Tests
 Component:  tests   |     Version:  1.0                 
Resolution:          |    Keywords:  tps                 
---------------------+------------------------------------------------------
Comment (by jlaska):

 Whenever playing with the package set on our test systems, we run the risk
 of a test failure without the chance of cleaning up after itself.  I
 wonder if it's worth exploring appliance-creator to build and use a throw-
 away environment on the test system.  I wouldn't expect the test to have
 to handle these details, but seems like something we can instrument in the
 autotest wrapper itself.  After all, this is specific to our test
 infrastructure implementation, not the test.

-- 
Ticket URL: <https://fedorahosted.org/autoqa/ticket/128#comment:3>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project

[fedora-badges]

#128: pst: Create a mechanism to ensure test clients are fully up-to-date
---------------------+------------------------------------------------------
  Reporter:  kparal  |       Owner:                      
      Type:  task    |      Status:  new                 
  Priority:  major   |   Milestone:  Package Sanity Tests
 Component:  tests   |     Version:  1.0                 
Resolution:          |    Keywords:  tps                 
---------------------+------------------------------------------------------
Changes (by jlaska):

 * cc: mmcgrath (added)

Comment:

 mmcgrath demo'd a clever way of creating disposable virt guests for use
 with our tests.  I've modified the script slightly to make the
 requirements more explicit.  The general idea is ...
  * Create a master virt guest on the test system backed by a local volume
  * When a test needs a disposable system, use the attached script to
 create a slave virt guest
    * new guest storage uses an LVM snapshot of the ''master'' guest
    * any changes in new slave guest are not saved to the ''master'' LVM
 volume
  * Periodically, keep the master guest updated to the latest content

 mmcgrath and I discussed several techniques for using this.
  1. Use the setup above to create dedicated test clients for autotest used
 for any AutoQA tests that do not require virt
     * Pros
       * No/little code required
     * Cons
       * Autotest virt test clients would need to be setup to not accept
 any KVM jobs.  Virt guests can't create more virt guests.  Might be
 confusing if jobs fail on these test clients b/c they wouldn't support
 Virt
  1. Or, add the above logic to the setup() and teardown() methods of a new
 autotest test class inherited from ''autotest/client/bin/test::test()''
 which can be used by any AutoQA tests.
     * Pros
       * transparent to the tester
       * allows us to maintain all autotest test clients as KVM guests
 (don't need to worry about virt capable vs non-virt client systems)
     * Cons
       * might be a pain to administer, not sure ... would need to test

-- 
Ticket URL: <https://fedorahosted.org/autoqa/ticket/128#comment:4>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project