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