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

[James Bottomley]

On Thu, 2016-01-07 at 16:55 -0800, Yuhong Bao wrote:
> > > I read the patent and it looks like UEFI or for that matter any
> > > non
> > > -Windows implementation of FAT would probably not infringe on the
> > > patent.
> > 
> > Well, I'm not going to give you a legal opinion. However, most
> > people
> > think this patent covers the long vs short filenames conversions
> > used
> > by vfat. The UEFI implementation definitely implements the long vs
> > short name conversions for FAT/VFAT compatibility.
> > 
> > James
> 
> I actually read the claims in the patent and my point is that it
> mostly only covers the INT 21h interface in Win9x,
> which UEFI or for that matter Linux don't use.

Um, that's the first two independent claims.  The long filename stuff
begins at claim 4.

James



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[James Bottomley]

On Thu, 2016-01-07 at 18:03 +, Yuhong Bao wrote:
> James Bottomley  writes:
> > As you can see, they're mostly expired (in the US) but the last one
> > will expire in 2020 (if I calculate the date correctly).
> If you are referring to US6286013, 

That's the latest expiring one, yes.

> I read the patent and it looks like UEFI or for that matter any non
> -Windows implementation of FAT would probably not infringe on the
> patent.

Well, I'm not going to give you a legal opinion.  However, most people
think this patent covers the long vs short filenames conversions used
by vfat.  The UEFI implementation definitely implements the long vs
short name conversions for FAT/VFAT compatibility. 

James


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Yuhong Bao]

James Bottomley  writes:
> As you can see, they're mostly expired (in the US) but the last one
> will expire in 2020 (if I calculate the date correctly).
If you are referring to US6286013, I read the patent and it looks like 
UEFI or for that matter any non-Windows implementation of FAT would 
probably not infringe on the patent. 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[James Bottomley]

On Fri, 2015-12-04 at 08:46 -0500, Sean Dague wrote:
> On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> > On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
> > > 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.
> > 
> > As copyright holder, Intel could choose to change the license of
> > their
> > code to make it free software avoiding all the problems. None the
> > less,
> > as above, I don't think this is a blocker for inclusion of the
> > feature
> > in Nova, nor our testing of it.

Actually, it's a bit over simplified to claim this.  The origins of
this clause are in the covenants not to sue in the FAT spec:

http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-92
3143f3456c/fatgen103.doc

It's clause 1(e).  The reason for the clause is a complex negotiation
over the UEFI spec (Microsoft committed to a royalty free
implementation and UEFI needed to use FAT for backward compatibility
with older BIOS).  The problem is that the litigation history no longer
supports claiming the patents are invalid:

http://en.swpat.org/wiki/Microsoft_FAT_patents

As you can see, they're mostly expired (in the US) but the last one
will expire in 2020 (if I calculate the date correctly).  No
corporation (including Intel) can safely release a driver under a
licence that doesn't respect the FAT covenant not to sue without being
subject to potential accusations of contributory infringement.  So,
you're right, Intel could release the FAT 32 driver under a non
-restricted licence as you say but only if they effectively take on
liability for potential infringement for every downstream user ...
amazingly enough they don't want to do that.  Red Hat could do the
same, of course: just strip the additional restrictions clause; Intel
won't enforce it; then Red Hat would take on all the liability ...

The FAT driver is fully separated from the EDKII source:

https://github.com/tianocore/tianocore.github.io/wiki/Edk2-fat-driver

So it can easily be replaced.  The problem is how when every UEFI
driver or update comes on a FAT32 format system.

> That's fair. However we could also force having this conversation 
> again, and pay it forward to the larger open source community by 
> getting this ridiculous licensing fixed. We did the same thing with 
> some other libraries in the past.

The only way to "fix" the licence is to either get Microsoft to extend
the covenant not to sue to all open source projects (I suppose not
impossible given they're making friendlier open source noises) or wait
for the patents to expire.

James


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ren, Qiaowei]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: Friday, December 4, 2015 9:47 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Testing concerns around boot from UEFI
> spec
> 
> On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> > On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
> >> 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.
> >
> > The EDK codebase contains a FAT driver which has a license that
> > forbids reusing the code outside of the EDK project.
> >
> > [quote]
> > Additional terms: In addition to the forgoing, redistribution and use
> > of the code is conditioned upon the FAT 32 File System Driver and all
> > derivative works thereof being used for and designed only to read
> > and/or write to a file system that is directly managed by Intel's
> > Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
> > and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
> > Specifications v.2.0 and later (together the "UEFI Specifications");
> > only as necessary to emulate an implementation of the UEFI
> > Specifications; and to create firmware, applications, utilities and/or 
> > drivers.
> > [/quote]
> >
> > So while the code is open source, it is under a non-free license,
> > hence Fedora will not ship it. For RHEL we're reluctantly choosing to
> > ship it as an exception to our normal policy, since its the only
> > immediate way to make UEFI support available on x86 & aarch64
> >
> > So I don't think the license is a reason to refuse to allow the UEFI
> > feature into Nova though, nor should it prevent us using the current
> > EDK bios in CI for testing purposes. It is really just an issue for
> > distros which only want 100% free software.
> 
> For upstream CI that's also a bar that's set. So for 3rd party, it would 
> probably be
> fine, but upstream won't happen.
> 

Sorry, is there any decision about this? If 3rd CI needs to be added, we could 
also work on it. BTW, if so, the patches could not be merged when the 3rd CI 
could not still work, right?

Thanks,
Qiaowei

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

On 12/10/2015 2:21 AM, Ren, Qiaowei wrote:



-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Friday, December 4, 2015 9:47 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Testing concerns around boot from UEFI
spec

On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:

On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:

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.


The EDK codebase contains a FAT driver which has a license that
forbids reusing the code outside of the EDK project.

[quote]
Additional terms: In addition to the forgoing, redistribution and use
of the code is conditioned upon the FAT 32 File System Driver and all
derivative works thereof being used for and designed only to read
and/or write to a file system that is directly managed by Intel's
Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
Specifications v.2.0 and later (together the "UEFI Specifications");
only as necessary to emulate an implementation of the UEFI
Specifications; and to create firmware, applications, utilities and/or drivers.
[/quote]

So while the code is open source, it is under a non-free license,
hence Fedora will not ship it. For RHEL we're reluctantly choosing to
ship it as an exception to our normal policy, since its the only
immediate way to make UEFI support available on x86 & aarch64

So I don't think the license is a reason to refuse to allow the UEFI
feature into Nova though, nor should it prevent us using the current
EDK bios in CI for testing purposes. It is really just an issue for
distros which only want 100% free software.


For upstream CI that's also a bar that's set. So for 3rd party, it would 
probably be
fine, but upstream won't happen.



Sorry, is there any decision about this? If 3rd CI needs to be added, we could 
also work on it. BTW, if so, the patches could not be merged when the 3rd CI 
could not still work, right?

Thanks,
Qiaowei

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



We talked about this in the nova meeting today and agreed that as long 
as there is a warning emitted when this is used saying it's untested and 
therefore considered experimental, we'd be OK with letting this into 
mitaka. It's in Intel's best interest to provide functional testing for 
it, but it wouldn't be required in this case.


I'd like the spec amended for that and then I'm +2.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ren, Qiaowei]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: Friday, December 4, 2015 9:47 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Testing concerns around boot from UEFI
> spec
> 
> On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> > On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
> >> 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.
> >
> > The EDK codebase contains a FAT driver which has a license that
> > forbids reusing the code outside of the EDK project.
> >
> > [quote]
> > Additional terms: In addition to the forgoing, redistribution and use
> > of the code is conditioned upon the FAT 32 File System Driver and all
> > derivative works thereof being used for and designed only to read
> > and/or write to a file system that is directly managed by Intel's
> > Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
> > and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
> > Specifications v.2.0 and later (together the "UEFI Specifications");
> > only as necessary to emulate an implementation of the UEFI
> > Specifications; and to create firmware, applications, utilities and/or 
> > drivers.
> > [/quote]
> >
> > So while the code is open source, it is under a non-free license,
> > hence Fedora will not ship it. For RHEL we're reluctantly choosing to
> > ship it as an exception to our normal policy, since its the only
> > immediate way to make UEFI support available on x86 & aarch64
> >
> > So I don't think the license is a reason to refuse to allow the UEFI
> > feature into Nova though, nor should it prevent us using the current
> > EDK bios in CI for testing purposes. It is really just an issue for
> > distros which only want 100% free software.
> 
> For upstream CI that's also a bar that's set. So for 3rd party, it would 
> probably be
> fine, but upstream won't happen.
> 
> > Unless the license on the existing code gets resolved, some Red Hat
> > maintainers have a plan to replace the existing FAT driver with an
> > alternative impl likely under GPL. At that time, it'll be acceptable
> > for inclusion in Fedora.
> >
> >> 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.
> >
> > As copyright holder, Intel could choose to change the license of their
> > code to make it free software avoiding all the problems. None the
> > less, as above, I don't think this is a blocker for inclusion of the
> > feature in Nova, nor our testing of it.
> 
> That's fair. However we could also force having this conversation again, and 
> pay
> it forward to the larger open source community by getting this ridiculous
> licensing fixed. We did the same thing with some other libraries in the past.
> 

It should be due to MIT copyright addition that distributions like Fedora, 
Ubuntu, QEMU... don't include OVMF. But the MS patent looks like be recently 
expired. So the addition will be removed later, and once removed we will work 
to make OVMF a standard part of distributions.

Thanks,
Qiaowei

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Daniel P. Berrange]

On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
> 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.

The EDK codebase contains a FAT driver which has a license that forbids
reusing the code outside of the EDK project.

[quote]
Additional terms: In addition to the forgoing, redistribution and use
of the code is conditioned upon the FAT 32 File System Driver and all
derivative works thereof being used for and designed only to read
and/or write to a file system that is directly managed by Intel's
Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
Specifications v.2.0 and later (together the "UEFI Specifications");
only as necessary to emulate an implementation of the UEFI Specifications;
and to create firmware, applications, utilities and/or drivers.
[/quote]

So while the code is open source, it is under a non-free license,
hence Fedora will not ship it. For RHEL we're reluctantly choosing
to ship it as an exception to our normal policy, since its the only
immediate way to make UEFI support available on x86 & aarch64

So I don't think the license is a reason to refuse to allow the UEFI
feature into Nova though, nor should it prevent us using the current
EDK bios in CI for testing purposes. It is really just an issue for
distros which only want 100% free software.

Unless the license on the existing code gets resolved, some Red Hat
maintainers have a plan to replace the existing FAT driver with an
alternative impl likely under GPL. At that time, it'll be acceptable
for inclusion in Fedora.

> 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.

As copyright holder, Intel could choose to change the license of their
code to make it free software avoiding all the problems. None the less,
as above, I don't think this is a blocker for inclusion of the feature
in Nova, nor our testing of it.

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 :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
>> 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.
> 
> The EDK codebase contains a FAT driver which has a license that forbids
> reusing the code outside of the EDK project.
> 
> [quote]
> Additional terms: In addition to the forgoing, redistribution and use
> of the code is conditioned upon the FAT 32 File System Driver and all
> derivative works thereof being used for and designed only to read
> and/or write to a file system that is directly managed by Intel's
> Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
> and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
> Specifications v.2.0 and later (together the "UEFI Specifications");
> only as necessary to emulate an implementation of the UEFI Specifications;
> and to create firmware, applications, utilities and/or drivers.
> [/quote]
> 
> So while the code is open source, it is under a non-free license,
> hence Fedora will not ship it. For RHEL we're reluctantly choosing
> to ship it as an exception to our normal policy, since its the only
> immediate way to make UEFI support available on x86 & aarch64
> 
> So I don't think the license is a reason to refuse to allow the UEFI
> feature into Nova though, nor should it prevent us using the current
> EDK bios in CI for testing purposes. It is really just an issue for
> distros which only want 100% free software.

For upstream CI that's also a bar that's set. So for 3rd party, it would
probably be fine, but upstream won't happen.

> Unless the license on the existing code gets resolved, some Red Hat
> maintainers have a plan to replace the existing FAT driver with an
> alternative impl likely under GPL. At that time, it'll be acceptable
> for inclusion in Fedora.
> 
>> 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.
> 
> As copyright holder, Intel could choose to change the license of their
> code to make it free software avoiding all the problems. None the less,
> as above, I don't think this is a blocker for inclusion of the feature
> in Nova, nor our testing of it.

That's fair. However we could also force having this conversation again,
and pay it forward to the larger open source community by getting this
ridiculous licensing fixed. We did the same thing with some other
libraries in the past.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Fox, Kevin M]

I think efi can boot off of fat16 as well. for vm's, we may not need fat32 
support at all. Could we just remove the offending fat32 code?

Thanks,
Kevin

From: Sean Dague [s...@dague.net]
Sent: Friday, December 04, 2015 5:46 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
>> 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.
>
> The EDK codebase contains a FAT driver which has a license that forbids
> reusing the code outside of the EDK project.
>
> [quote]
> Additional terms: In addition to the forgoing, redistribution and use
> of the code is conditioned upon the FAT 32 File System Driver and all
> derivative works thereof being used for and designed only to read
> and/or write to a file system that is directly managed by Intel's
> Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
> and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
> Specifications v.2.0 and later (together the "UEFI Specifications");
> only as necessary to emulate an implementation of the UEFI Specifications;
> and to create firmware, applications, utilities and/or drivers.
> [/quote]
>
> So while the code is open source, it is under a non-free license,
> hence Fedora will not ship it. For RHEL we're reluctantly choosing
> to ship it as an exception to our normal policy, since its the only
> immediate way to make UEFI support available on x86 & aarch64
>
> So I don't think the license is a reason to refuse to allow the UEFI
> feature into Nova though, nor should it prevent us using the current
> EDK bios in CI for testing purposes. It is really just an issue for
> distros which only want 100% free software.

For upstream CI that's also a bar that's set. So for 3rd party, it would
probably be fine, but upstream won't happen.

> Unless the license on the existing code gets resolved, some Red Hat
> maintainers have a plan to replace the existing FAT driver with an
> alternative impl likely under GPL. At that time, it'll be acceptable
> for inclusion in Fedora.
>
>> 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.
>
> As copyright holder, Intel could choose to change the license of their
> code to make it free software avoiding all the problems. None the less,
> as above, I don't think this is a blocker for inclusion of the feature
> in Nova, nor our testing of it.

That's fair. However we could also force having this conversation again,
and pay it forward to the larger open source community by getting this
ridiculous licensing fixed. We did the same thing with some other
libraries in the past.

-Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tony Breeds]

On Thu, Dec 03, 2015 at 07:42:43PM -0600, Matt Riedemann wrote:

> 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].

We're woring on a devstack plugin that will allow us to test newer
libvirt/qemu.  Which doesn't really solve the testing problem but it helps.

Yours Tony.


pgp6B7ASk9IRU.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

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


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev