On 10/2/18 12:36 AM, Jay Pipes wrote:
On 10/01/2018 06:04 PM, Julia Kreger wrote:
On Mon, Oct 1, 2018 at 2:41 PM Eric Fried <openst...@fried.cc> wrote:
> So say the user requests a node that supports UEFI because their
image
> needs UEFI. Which workflow would you want here?
>
> 1) The operator (or ironic?) has already configured the node to
boot in
> UEFI mode. Only pre-configured nodes advertise the "supports
UEFI" trait.
>
> 2) Any node that supports UEFI mode advertises the trait. Ironic
ensures
> that UEFI mode is enabled before provisioning the machine.
>
> I imagine doing #2 by passing the traits which were specifically
> requested by the user, from Nova to Ironic, so that Ironic can do the
> right thing for the user.
>
> Your proposal suggests that the user request the "supports UEFI"
trait,
> and *also* pass some glance UUID which the user understands will make
> sure the node actually boots in UEFI mode. Something like:
>
> openstack server create --flavor METAL_12CPU_128G --trait
SUPPORTS_UEFI
> --config-data $TURN_ON_UEFI_UUID
>
> Note that I pass --trait because I hope that will one day be
supported
> and we can slow down the flavor explosion.
IMO --trait would be making things worse (but see below). I think UEFI
with Jay's model would be more like:
openstack server create --flavor METAL_12CPU_128G --config-data $UEFI
where the UEFI profile would be pretty trivial, consisting of
placement.traits.required = ["BOOT_MODE_UEFI"] and object.boot_mode =
"uefi".
I agree that this seems kind of heavy, and that it would be nice to be
able to say "boot mode is UEFI" just once. OTOH I get Jay's point that
we need to separate the placement decision from the instance
configuration.
That said, what if it was:
openstack config-profile create --name BOOT_MODE_UEFI --json -
{
"type": "boot_mode_scheme",
"version": 123,
"object": {
"boot_mode": "uefi"
},
"placement": {
"traits": {
"required": [
"BOOT_MODE_UEFI"
]
}
}
}
^D
And now you could in fact say
openstack server create --flavor foo --config-profile BOOT_MODE_UEFI
using the profile name, which happens to be the same as the trait name
because you made it so. Does that satisfy the yen for saying it once? (I
mean, despite the fact that you first had to say it three times to get
it set up.)
========
I do want to zoom out a bit and point out that we're talking about
implementing a new framework of substantial size and impact when the
original proposal - using the trait for both - would just work out of
the box today with no changes in either API. Is it really worth it?
+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.
========
By the way, with Jim's --trait suggestion, this:
> ...dozens of flavors that look like this:
> - 12CPU_128G_RAID10_DRIVE_LAYOUT_X
> - 12CPU_128G_RAID5_DRIVE_LAYOUT_X
> - 12CPU_128G_RAID01_DRIVE_LAYOUT_X
> - 12CPU_128G_RAID10_DRIVE_LAYOUT_Y
> - 12CPU_128G_RAID5_DRIVE_LAYOUT_Y
> - 12CPU_128G_RAID01_DRIVE_LAYOUT_Y
...could actually become:
openstack server create --flavor 12CPU_128G --trait $WHICH_RAID
--trait
$WHICH_LAYOUT
No flavor explosion.
++ I believe this was where this discussion kind of ended up in.. ?Dublin?
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.
(Maybe if we called it something other than --trait, like maybe
--config-option, it would let us pretend we're not really overloading a
trait to do config - it's just a coincidence that the config option has
the same name as the trait it causes to be required.)
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.
I guess I'll just drop the idea of doing this properly then. It's true that the
placement traits concept can be hacked up and the virt driver can just pass a
list of trait strings to the Ironic API and that's the most expedient way to get
what the 90% of people apparently want. It's also true that it will add a bunch
of unmaintainable tribal knowledge into the interface between Nova and Ironic,
but that has been the case for multiple years.
Mostly a side note: this has been always the case and probably will be :( For
example, this is just some black magic for everyone outside of our teams I've
ever talked to:
$ openstack flavor set --property resources:VCPU=0 my-baremetal-flavor
$ openstack flavor set --property resources:MEMORY_MB=0 my-baremetal-flavor
$ openstack flavor set --property resources:DISK_GB=0 my-baremetal-flavor
People got used to doing it, but for them it's just "magical commands to make
Ironic work starting with Rocky".
The flavor explosion problem will continue to get worse for those of us who deal
with its pain (Oath in particular feels this) because the interface between nova
flavors and Ironic instance capabilities will continue to be super-tightly-coupled.
For the record, I would have been happier if someone had proposed separating the
instance configuration data in the flavor extra-specs from the notion of
required placement constraints (i.e. traits). You could call the extra_spec
"deploy_template_id" if you wanted and that extra spec value could have been
passed to Ironic during node provisioning instead of the list of placement
constraints (traits).
I like it, but I guess it has two downsides:
1. Adding something to Nova API just for Ironic.
2. Ability for operators to shoot their legs by requesting some RAID
configuration via deploy_template_id but not requesting the ability to use RAID
in traits.
Also will it really help with flavor explosion, unless we allow to pass this
deploy_template_id via user-facing API?
Dmitry
So, you'd have a list of actual placement traits for an instance that looked
like this:
required=BOOT_MODE_UEFI,STORAGE_HARDWARE_RAID
and you'd have a flavor extra spec called "deploy_template_id" with a value of
the deploy template configuration data you wanted to communicate to Ironic. The
Ironic virt driver could then just look for the "deploy_template_id" extra spec
and pass the value of that to the Ironic API instead of passing a list of traits.
That would have at least satisfied my desire to separate configuration data from
placement constraints.
Anyway, I'm done trying to please my own desires for a clean solution to this.
Best,
-jay
__________________________________________________________________________
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
