[openstack-dev] [nova] Testing concerns around boot from UEFI spec

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Dec 3 15:35:19 UTC 2015


The boot from UEFI spec [1] is stalled a bit on testing concerns. I've 
asked that there is integration testing (either upstream or Intel hosts 
a 3rd party job for it), or we log a warning when it's used saying it's 
untested and therefore considered experimental.

I think we also want to point out UEFI boot support in the hypervisor 
support matrix for this change, which leads me to what I think are the 
three options:

1. Don't test it; this is the easy short term answer. We log the warning 
that it's not tested and considered experimental. This is easy and 
side-steps the quality issue, but also goes against our direction as a 
project. [2][3]

2. Require Intel to provide a 3rd party CI job to test this. It sounds 
like this might be a possibility, but I'm not entirely sure if it's 
necessary given the last option.

3. Get this working in devstack and add a flag to Tempest for it, then 
we can run it in the normal gate-tempest-dsvm-full job. I think the 
steps (at a high level) to make this work are:

a) install ovmf (this is in ubuntu 14.04)
b) setup an image with the proper uefi image metadata
c) configure tempest with the uefi image id (if None, it means boot from 
uefi is not supported for the given env)
d) add a test to boot from uefi using the given uefi image id

I think before we can know how feasible #3 is, someone has to test that 
out (not it!). But given the spec freeze deadline is today, how do we 
proceed?

We could say in the spec #1 is the short term plan, but emphasize that 
#3 will be investigated (but not required for the code to land in mitaka).

Unless of course people want to make 2 or 3 required for the code to land.

I'll add this to the nova meeting agenda for today.

[1] https://review.openstack.org/#/c/235983/
[2] https://review.openstack.org/#/c/252543/
[3] https://review.openstack.org/#/c/215664/9/doc/source/test_strategy.rst

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list