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 <j...@jimrollenhagen.com<mailto:j...@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@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
On Feb 22, 2016, at 15:15, Chris K <
nobody...@gmail.com<mailto:nobody...@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-requ...@lists.openstack.org<mailto: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
