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

Heck, Joseph Joseph.Heck at emc.com
Tue Feb 23 14:22:56 UTC 2016


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<mailto: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<mailto:openstack-dev at lists.openstack.org>>



On Feb 22, 2016, at 15:15, Chris K < nobodycam at gmail.com<mailto: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<mailto: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/a0d002f3/attachment.html>


More information about the OpenStack-dev mailing list