[openstack-dev] [nova] test strategy for the serial console feature

Daniel P. Berrange berrange at redhat.com
Thu Aug 11 15:27:46 UTC 2016


On Thu, Aug 11, 2016 at 04:46:02PM +0200, Markus Zoeller wrote:
> On 11.08.2016 13:31, Daniel P. Berrange wrote:
> > On Thu, Aug 11, 2016 at 07:19:42AM -0400, Sean Dague wrote:
> >> On 08/11/2016 05:45 AM, Markus Zoeller wrote:
> >>> On 26.07.2016 12:16, Jordan Pittier wrote:
> >>>> Hi Markus
> >>>> You don"t really need a whole new job for this. Just turn that flag to True
> >>>> on existing jobs.
> >>>>
> >>>> 30/40 seconds is acceptable. But I am surprised considering a VM usually
> >>>> boots in 5 sec or so. Any idea of where that slowdown comes from ?
> >>>>
> >>>> On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller <
> >>>> mzoeller at linux.vnet.ibm.com> wrote:
> >>
> >> We just had a big chat about this in the #openstack-nova IRC channel. To
> >> summarize:
> >>
> >> The class of bugs that are really problematic are:
> >>
> >>  * https://bugs.launchpad.net/nova/+bug/1455252 - Launchpad bug 1455252
> >> in OpenStack Compute (nova) "enabling serial console breaks live
> >> migration" [High,In progress] - Assigned to sahid (sahid-ferdjaoui)
> >>
> >> * https://bugs.launchpad.net/nova/+bug/1595962 - Launchpad bug 1595962
> >> in OpenStack Compute (nova) "live migration with disabled vnc/spice not
> >> possible" [Undecided,In progress] - Assigned to Markus Zoeller
> >> (markus_z) (mzoeller)
> >>
> >> Which are both in the category of serial console breaking live
> >> migration. It's the serial device vs. live migration that's most
> >> problematic. Serial consoles themselves haven't broken badly recently.
> >> Given that we don't do live migration testing in most normal jobs, the
> >> Tempest jobs aren't really going to help here.
> >>
> >> The dedicated live-migration job is being targeted.
> >>
> >> Serial console support is currently a function at the compute level.
> >> Which is actually a little odd. Because it means that all guests on a
> >> compute must be serial console, or must not. Imagine a compute running
> >> Linux, Windows, FreeBSD guests. It's highly unlikely that you want to
> >> force serial console one way or another on all of those the same way.
> >> This is probably something that makes sense to add as an image
> >> attribute, because images will need guest configuration to support
> >> serial consoles. As an image attribute this would also help on testing
> >> because we could mix / match in a single run.
> > 
> > There is actually image properties for this, but the way it is all
> > implemented right now is just insane.
> 
> You're talking about "hw_serial_port_count" I assume? I'm not aware of
> any other property for that. Sean was talking about enabling the serial
> console per image/flavor property IIUC.

If hw_serial_port_count allowed a value of '0', and we fixed the
problem of the other random serial port with type=pty we create,
then we'd get the full serial console per image support Sean
wants when nova.conf was set to serial_console.enabled=True.

We could also discuss / notify users that we're intending to set
that nova.conf to default to True in a future release, and
then eventually delete the nova.conf setting entirely.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



More information about the OpenStack-dev mailing list