[openstack-dev] [placement] The "intended purpose" of traits
jaypipes at gmail.com
Fri Sep 28 16:12:47 UTC 2018
On 09/28/2018 09:25 AM, Eric Fried wrote:
> It's time somebody said this.
> Every time we turn a corner or look under a rug, we find another use
> case for provider traits in placement. But every time we have to have
> the argument about whether that use case satisfies the original
> "intended purpose" of traits.
> That's only reason I've ever been able to glean: that it (whatever "it"
> is) wasn't what the architects had in mind when they came up with the
> idea of traits.
Don't pussyfoot around things. It's me you're talking about, Eric. You
could just ask me instead of passive-aggressively posting to the list
> We're not even talking about anything that would require changes to
> the placement API. Just, "Oh, that's not a *capability* - shut it
That's precisely the attitude that got the Nova scheduler into the
unmaintainable and convoluted mess that it is now: "well, who cares if a
concept was originally intended to describe X, it's just *easier* for us
to re-use this random piece of data in ways it wasn't intended because
that way we don't have to change anything about our docs or our API".
And *this* is the kind of stuff you end up with:
Which is a pile of unreadable, unintelligible garbage; nobody knows how
it works, how it originally was intended to work, or how to really clean
> Bubble wrap was originally intended as a textured wallpaper and a
> greenhouse insulator. Can we accept the fact that traits have (many,
> many) uses beyond marking capabilities, and quit with the arbitrary
They aren't arbitrary. They are there for a reason: a trait is a boolean
capability. It describes something that either a provider is capable of
supporting or it isn't.
Conceptually, having boolean traits/capabilities is important because it
allows the user to reason simply about how a provider meets the
requested constraints for scheduling.
Currently, those constraints include the following:
* Does the provider have *capacity* for the requested resources?
* Does the provider have the required (or forbidden) *capabilities*?
* Does the provider belong to some group?
If we want to add further constraints to the placement allocation
candidates request that ask things like:
* Does the provider have version 1.22.61821 of BIOS firmware from
Marvell installed on it?
* Does the provider support an FPGA that has had an OVS program flashed
to it in the last 20 days?
* Does the provider belong to physical network "corpnet" and also
support creation of virtual NICs of type either "DIRECT" or "NORMAL"?
Then we should add a data model that allow providers to be decorated
with key/value (or more complex than key/value) information where we can
query for those kinds of constraints without needing to encode all sorts
of non-binary bits of information into a capability string.
Propose such a thing and I'll gladly support it. But I won't support
bastardizing the simple concept of a boolean capability just because we
don't want to change the API or database schema.
More information about the OpenStack-dev