Open Stack

On Mon, Oct 1, 2018 at 6:38 PM Jay Pipes <jaypipes at gmail.com> 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:
>
> <snip>

>
> >     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.)
> >
> <snip>
> >
> > 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.
>
> 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).
>
> 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.
>

Jay, please don't stop - I think we aren't expressing ourselves well, or
you're missing something, or both. I understand this is a frustrating
conversation for everyone. But I think we're making good progress on the
end goal (whether or not we do an intermediate step that hacks on top of
traits). We all want a clean solution to this.

What Eric is proposing (and Julia and I seem to be in favor of), is nearly
the same as your proposal. The single difference is that these config
templates or deploy templates or whatever could *also* require certain
traits, and the scheduler would use that information to pick a node. While
this does put some scheduling information into the config template, it also
means that we can remove some of the flavor explosion *and* mostly separate
scheduling from configuration.

So, you'd have a list of traits on a flavor:

required=HW_CPU_X86_VMX,HW_NIC_ACCEL_IPSEC

And you would also have a list of traits in the deploy template:

{"traits": {"required": ["STORAGE_HARDWARE_RAID"]}, "config": <RAID blob>}

This allows for making flavors that are reasonably flexible (instead of two
flavors that do VMX and IPSEC acceleration, one of which does RAID). It
also allows users to specify a desired configuration without also needing
to know how to correctly choose a flavor that can handle that configuration.

I think it makes a lot of sense, doesn't impose more work on users, and can
reduce the number of flavors operators need to manage.

Does that make sense?

// jim


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181002/ccf67567/attachment.html>