<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 1, 2018 at 2:41 PM Eric Fried <openstack@fried.cc> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> So say the user requests a node that supports UEFI because their image<br>
> needs UEFI. Which workflow would you want here?<br>
> <br>
> 1) The operator (or ironic?) has already configured the node to boot in<br>
> UEFI mode. Only pre-configured nodes advertise the "supports UEFI" trait.<br>
> <br>
> 2) Any node that supports UEFI mode advertises the trait. Ironic ensures<br>
> that UEFI mode is enabled before provisioning the machine.<br>
> <br>
> I imagine doing #2 by passing the traits which were specifically<br>
> requested by the user, from Nova to Ironic, so that Ironic can do the<br>
> right thing for the user.<br>
> <br>
> Your proposal suggests that the user request the "supports UEFI" trait,<br>
> and *also* pass some glance UUID which the user understands will make<br>
> sure the node actually boots in UEFI mode. Something like:<br>
> <br>
> openstack server create --flavor METAL_12CPU_128G --trait SUPPORTS_UEFI<br>
> --config-data $TURN_ON_UEFI_UUID<br>
> <br>
> Note that I pass --trait because I hope that will one day be supported<br>
> and we can slow down the flavor explosion.<br>
<br>
IMO --trait would be making things worse (but see below). I think UEFI<br>
with Jay's model would be more like:<br>
<br>
openstack server create --flavor METAL_12CPU_128G --config-data $UEFI<br>
<br>
where the UEFI profile would be pretty trivial, consisting of<br>
placement.traits.required = ["BOOT_MODE_UEFI"] and object.boot_mode =<br>
"uefi".<br>
<br>
I agree that this seems kind of heavy, and that it would be nice to be<br>
able to say "boot mode is UEFI" just once. OTOH I get Jay's point that<br>
we need to separate the placement decision from the instance configuration.<br>
<br>
That said, what if it was:<br>
<br>
openstack config-profile create --name BOOT_MODE_UEFI --json -<br>
{<br>
"type": "boot_mode_scheme",<br>
"version": 123,<br>
"object": {<br>
"boot_mode": "uefi"<br>
},<br>
"placement": {<br>
"traits": {<br>
"required": [<br>
"BOOT_MODE_UEFI"<br>
]<br>
}<br>
}<br>
}<br>
^D<br>
<br>
And now you could in fact say<br>
<br>
openstack server create --flavor foo --config-profile BOOT_MODE_UEFI<br>
<br>
using the profile name, which happens to be the same as the trait name<br>
because you made it so. Does that satisfy the yen for saying it once? (I<br>
mean, despite the fact that you first had to say it three times to get<br>
it set up.)<br>
<br>
========<br>
<br>
I do want to zoom out a bit and point out that we're talking about<br>
implementing a new framework of substantial size and impact when the<br>
original proposal - using the trait for both - would just work out of<br>
the box today with no changes in either API. Is it really worth it?<br>
<br></blockquote><div><br></div><div>+1000. Reading both of these threads, it feels like we're basically trying to make something perfect. I think that is a fine goal, except it is unrealistic because the enemy of good is perfection.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
========<br>
<br>
By the way, with Jim's --trait suggestion, this:<br>
<br>
> ...dozens of flavors that look like this:<br>
> - 12CPU_128G_RAID10_DRIVE_LAYOUT_X<br>
> - 12CPU_128G_RAID5_DRIVE_LAYOUT_X<br>
> - 12CPU_128G_RAID01_DRIVE_LAYOUT_X<br>
> - 12CPU_128G_RAID10_DRIVE_LAYOUT_Y<br>
> - 12CPU_128G_RAID5_DRIVE_LAYOUT_Y<br>
> - 12CPU_128G_RAID01_DRIVE_LAYOUT_Y<br>
<br>
...could actually become:<br>
<br>
openstack server create --flavor 12CPU_128G --trait $WHICH_RAID --trait<br>
$WHICH_LAYOUT<br>
<br>
No flavor explosion.<br></blockquote><div><br></div><div>++ I believe this was where this discussion kind of ended up in.. ?Dublin?</div><div><br></div><div>The desire and discussion that led us into complex configuration templates and profiles being submitted were for highly complex scenarios where users wanted to assert detailed raid configurations to disk. Naturally, there are many issues there. The ability to provide such detail would be awesome for those 10% of operators that need such functionality. Of course, if that is the only path forward, then we delay the 90% from getting the minimum viable feature they need.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(Maybe if we called it something other than --trait, like maybe<br>
--config-option, it would let us pretend we're not really overloading a<br>
trait to do config - it's just a coincidence that the config option has<br>
the same name as the trait it causes to be required.)<br></blockquote><div><br></div><div>I feel like it might be confusing, but totally +1 to matching required trait name being a thing. That way scheduling is completely decoupled and if everything was correct then the request should already be scheduled properly.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-efried<br>
.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>