Open Stack

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 <openstack at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev