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. >
Unfortunately, by enabling the serial console, I disable the console log file. This is due to the decision at: https://github.com/openstack/nova/blob/2099ce73d87038983f01f639ddd1bc8f15b16729/nova/virt/libvirt/driver.py#L4081-L4111 Changing that would increase the number of devices which can then hit the upper bound of 4 serial devices in Qemu. I discussed this with danpb some time ago. This gets resolved when the "virtlogd" change is merged (hopefully in Ocata): https://blueprints.launchpad.net/nova/+spec/libvirt-virtlogd Hence my assumption that we need a new test job which configures tempest with: [compute-feature-enabled] console_output = False # default is 'True' serial_console = True # default is 'False' > 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 ? It could be my testing environment. I tested it with a (KVM) guest with 4 VCPUs and 4GB RAM, which is the host for a Devstack environment. -- Regards, Markus Zoeller (markus_z) > On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller < > [email protected]> wrote: > >> I'd like to discuss a testing strategy which ensures that the "serial >> console" feature in Nova doesn't break. Right now it's broken again [1]. >> This happens every once in a while as we don't test it in our CI >> environment. I pushed [2] which should be the start of a change series >> which checks: >> * does the "get-serial-console" API return the expected result >> * is a connection to the instance via serial console possible >> * is the live-migration still possible >> * are the resources (ports) cleaned up correctly >> >> I can create a new testing job for that which enables the serial console >> in the nova config: >> >> [serial_console] >> enabled = True >> >> My concern is that I could burn unnecessary many testing nodes for that >> and my question is, are there are other ways which are less testing >> resource hungry? >> >> I also noticed that it takes up to 30 seconds (locally) until the >> instance is booted completely and accepts console input, which makes the >> test run for [3] a very long one. >> >> References: >> [1] https://bugs.launchpad.net/nova/+bug/1455252 >> [2] https://review.openstack.org/#/c/346815/1 >> [3] https://review.openstack.org/#/c/346911/1 >> >> -- >> Regards, Markus Zoeller (markus_z) >> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
