Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec
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
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
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
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
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
> -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
> -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
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
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
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
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
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
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
[openstack-dev] [nova] Testing concerns around boot from UEFI spec
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 __ 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