[openstack-dev] [placement] The "intended purpose" of traits
melwittt at gmail.com
Fri Sep 28 21:07:44 UTC 2018
On Fri, 28 Sep 2018 15:42:23 -0500, Eric Fried wrote:
> On 09/28/2018 09:41 AM, Balázs Gibizer wrote:
>> On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried <openstack at fried.cc> 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. 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."
>>> 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
>> How far are we willing to go? Does an arbitrary (key: value) pair
>> encoded in a trait name like key_`str(value)` (e.g. CURRENT_TEMPERATURE:
>> 85 encoded as CUSTOM_TEMPERATURE_85) something we would be OK to see in
> Great question. Perhaps TEMPERATURE_DANGEROUSLY_HIGH is okay, but
> TEMPERATURE_<specific_number> is not. This thread isn't about setting
> these parameters; it's about getting us to a point where we can discuss
> a question just like this one without running up against:
> "That's a hard no, because you shouldn't encode key/value pairs in traits."
> "Oh, why's that?"
> "Because that's not what we intended when we created traits."
> "But it would work, and the alternatives are way harder."
I think it's not so much about the intention when traits were created
and more about what UX callers of the API are left with, if we were to
recommend representing everything with traits and not providing another
API for key-value use cases. We need to think about what the maintenance
of their deployments will look like if traits are the only tool we provide.
I get that we don't want to put artificial restrictions on how API
callers can and can't use the traits API, but will they be left with a
manageable experience if that's all that's available?
I don't have time right now to come up with a really great example, but
I'm thinking along the lines of, can this get out of hand (a la "flavor
explosion") for an operator using traits to model what their compute
hosts can do?
Please forgive the oversimplified example I'm going to try to use to
illustrate my concern:
We all agree we can have traits for resource providers like:
But things get less straightforward when we think of traits like:
I'm concerned about a lot of repetition here and maintenance headache
for operators. That's where the thoughts about whether we should provide
something like a key-value construct to API callers where they can
for each resource provider.
If I'm off base with my example, please let me know. I'm not a placement
Anyway, I hope that gives an idea of what I'm thinking about in this
discussion. I agree we need to pick a direction and go with it. I'm just
trying to look out for the experience operators are going to be using
this and maintaining it in their deployments.
More information about the OpenStack-dev