Open Stack

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
>>> restrictions?
>>
>> 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
>> placement?
> 
> 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."
> 
> "-1"
> 
> "But..."
> 
> "-1"
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:

* HAS_SSD
* HAS_GPU
* HAS_WINDOWS

But things get less straightforward when we think of traits like:

* HAS_OWNER_CINDER
* HAS_OWNER_NEUTRON
* HAS_OWNER_CYBORG
* HAS_RAID_0
* HAS_RAID_1
* HAS_RAID_5
* HAS_RAID_6
* HAS_RAID_10
* HAS_NUMA_CELL_0
* HAS_NUMA_CELL_1
* HAS_NUMA_CELL_2
* HAS_NUMA_CELL_3

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 
instead say:

* OWNER=CINDER
* RAID=10
* NUMA_CELL=0

for each resource provider.

If I'm off base with my example, please let me know. I'm not a placement 
expert.

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.

Cheers,
-melanie