[openstack-dev] [ironic] [stable] iPXE / UEFI support for stable liberty

Chris K nobodycam at gmail.com
Tue Feb 23 15:48:50 UTC 2016


Thank you for the replies,
I have abandon the patches, upon re-review and testing of the case I
thought was working I agree that these patches are beyond the scope of what
a backport should be.

Chris

On Tue, Feb 23, 2016 at 6:22 AM, Heck, Joseph <Joseph.Heck at emc.com> wrote:

> Morning,
>
> Just a quick note, there is UEFI booting support within iPXE.  You have to
> invoke a specific build of the binary to get the output, but it's there:
>      make bin-x86_64-efi/snponly.efi
>
> Not entirely relevant to the core of the thread, but wanted to share that
> detail if it's been otherwise missed.
>
> - joe
> _____________________________
> From: Jim Rollenhagen <jim at jimrollenhagen.com>
> Sent: Monday, February 22, 2016 7:37 PM
> Subject: Re: [openstack-dev] [ironic] [stable] iPXE / UEFI support for
> stable liberty
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
>
>
>
>
> On Feb 22, 2016, at 15:15, Chris K < nobodycam at gmail.com> wrote:
>
> Hi Ironicers,
>
> I wanted to draw attention to iPXE / UEFI support in our stable liberty
> branch.
>
>
> Which doesn't exist, right? Or does it work depending on some other
> factors?
>
> There are environments that require support for UEFI, while ironic does
> have this support in master, it is not capable of this in many
> configurations when using the stable liberty release and the docs around
> this feature were unclear.
>
>
> What's unclear about the docs? Can you point at a specific thing, or is it
> just the lack of a thing that specifically says UEFI+iPXE is not supported?
>
> Because support for this feature was unclear when the liberty branch was
> cut it has caused some confustion to users wishing or needing to consume
> the stable branch. I have purposed patches
> https://review.openstack.org/#/c/281564 and
> https://review.openstack.org/#/c/281536 with the goal of correcting this,
> given that master may not be acceptable for some businesses to consume. I
> welcome feedback on this.
>
>
> I believe the first patch adds the feature, and the second patch fixes a
> bug with the feature. Correct?
>
> As you know, stable policy is to not backport features. I don't see any
> reason this case should bypass this policy (which is why I asked so many
> questions above, it's odd to me that this is an open question at all).
>
> It seems like a better path would be to fix the docs to avoid the
> confusion in the first place, right? I'm not sure what the "backport" would
> look like, given that docs patch wouldn't make sense on master, but surely
> some more experienced stable maintainers could guide us. :)
>
> // jim
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160223/a762bc21/attachment.html>


More information about the OpenStack-dev mailing list