Bug 847103

This bug fails RHEV-H tests, involving upgrade. Marking it as testblocker.

IIRC we need to handle this change from a blocking reboot to a non-blocking reboot during some installation cases. Otherwise e.g. a login prompt will be displayed in the auto-installation case.

(In reply to comment #7)
> IIRC we need to handle this change from a blocking reboot to a non-blocking
> reboot during some installation cases. Otherwise e.g. a login prompt will be
> displayed in the auto-installation case.

I don't understand... which login prompt? Even while sleeping there was one, or people could ssh to machine.

(In reply to comment #8)
> (In reply to comment #7)
> > IIRC we need to handle this change from a blocking reboot to a non-blocking
> > reboot during some installation cases. Otherwise e.g. a login prompt will be
> > displayed in the auto-installation case.
> 
> I don't understand... which login prompt? Even while sleeping there was one,
> or people could ssh to machine.

I wasn't aware that a login prompt appeared in the auto-install case, this should normally prevented by the sleep.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > IIRC we need to handle this change from a blocking reboot to a non-blocking
> > > reboot during some installation cases. Otherwise e.g. a login prompt will be
> > > displayed in the auto-installation case.
> > 
> > I don't understand... which login prompt? Even while sleeping there was one,
> > or people could ssh to machine.
> 
> I wasn't aware that a login prompt appeared in the auto-install case, this
> should normally prevented by the sleep.

I am sorry, but I don't understand why the login prompt is an issue... :)

It's not a critical but a cosmetic issue we had in the past. I've got an up- and downstream patch which I'm going to test now.

It turns out that one side effect is, that after an auto-install all subsequent services are booted until the login prompt is displayed.
This is more cosmetic but can distract users.

My understanding is that this issue is solved in latest builds by a change in the vdsm code to use the python code in the iso image directly rather than the legacy bash scripts.  Because of that change, we're not hitting the sleep timeout issue anymore.  

Is this correct?  If so, can we mark this testonly?

Mike,

I tried this[1] image.

1. There is no /data/updates in new image, so image upload fails.

2. After I create /data/updates, update succeeds but no reboot.

3. Another issue: after I approve, vdsm does not come up:

[root@alonbl4 ~]# /etc/init.d/vdsmd start
checking certs..
vdsm: libvirt already configured for vdsm                  [  OK  ]
Starting iscsid: 
vdsm: Failed to define network filters on libvirt          [FAILED]

Do you have rhev-m environment to test?


[1] http://jenkins.virt.bos.redhat.com/jenkins/view/RHEL%206/job/rhev-hypervisor-6-z-stream-rhev-31/

(In reply to comment #18)
> Mike,
> 
> I tried this[1] image.
> 
> 1. There is no /data/updates in new image, so image upload fails.

/data/updates is created by vdsm on startup.  This is caused by (#3) vdsm failing to start

> 
> 2. After I create /data/updates, update succeeds but no reboot.

Partially ovirt-node, partially vdsm.  Patches posted upstream:

http://gerrit.ovirt.org/7777
http://gerrit.ovirt.org/7778

> 
> 3. Another issue: after I approve, vdsm does not come up:

Pure vdsm
> 
> [root@alonbl4 ~]# /etc/init.d/vdsmd start
> checking certs..
> vdsm: libvirt already configured for vdsm                  [  OK  ]
> Starting iscsid: 
> vdsm: Failed to define network filters on libvirt          [FAILED]
> 
> Do you have rhev-m environment to test?
> 
> 
> [1]
> http://jenkins.virt.bos.redhat.com/jenkins/view/RHEL%206/job/rhev-hypervisor-
> 6-z-stream-rhev-31/

in testing on 6.3.z, QE has found the following:

old RHEVH   New RHEVH      RHEVM          Result
3.0         3.0            3.0            Pass
3.1         3.1            3.1            Pass
3.0         3.1            3.0            Pass
3.0         3.1            3.1            Fail (upgrade is successful, but shows failure in RHEV-M

Correction, the following scenario was not tested yet:

3.0         3.1            3.0            Pass

Ying, 

Can you provide an update after testing 3.0 -> 3.1 on RHEVM 3.0?

(In reply to comment #32)
> Ying, 
> 
> Can you provide an update after testing 3.0 -> 3.1 on RHEVM 3.0?

Test hypervisor6-6.3-20121012.0.el6_3 upgrade to hypervisor6-6.3-20121015.0.rhev31.el6_3, it is successful, so 3.0 -> 3.1 on RHEVM 3.0 IC is PASS.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0556.html