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
__________________________________________________________________________
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
