Open Stack

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 
like this.

> We're not even talking about anything that would require changes to
> the placement API. Just, "Oh, that's not a *capability* - shut it
> down."
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:

https://github.com/openstack/nova/blob/99bf62e42701397690fe2b4987ce4fd7879355b8/nova/scheduler/filters/compute_capabilities_filter.py#L35-L107

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 
it up.

> 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
> restrictions?

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.

-jay