Open Stack

On 12/03/2015 08:42 PM, Matt Riedemann wrote:
> 
> 
> On 12/3/2015 9:35 AM, Matt Riedemann wrote:
>> 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
>>
> 
> I already mentioned this to sdague before the nova meeting today (these
> are the things I think about while driving in the middle of nowhere),
> but option #3 won't work because boot from UEFI requires libvirt>=1.9.0,
> which we don't have in the gate (ubuntu 14.04 has liberty 1.2.2).  There
> is a newer version of libvirt in the fc21 job in the experimental queue,
> but ovmf isn't available from Fedora [1].
> 
> [1]
> https://fedoraproject.org/wiki/Using_UEFI_with_QEMU#EDK2_Licensing_Issues

Can someone explain the licensing issue here? The Fedora comments make
this sound like this is something that's not likely to end up in distros.

That seems weird enough that I'd rather push back on our Platinum Board
member to fix the licensing before we let this in. Especially as this
feature is being drive by Intel.

	-Sea

-- 
Sean Dague
http://dague.net