Open Stack

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 <
> mzoeller at linux.vnet.ibm.com> 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)
>>