Open Stack

On 09/28/2018 04:42 PM, 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.

That's correct, because you're encoding >1 piece of information into the 
single string (the fact that it's a temperature *and* the value of that 
temperature are the two pieces of information encoded into the single 
string).

Now that there's multiple pieces of information encoded in the string 
the reader of the trait string needs to know how to decode those bits of 
information, which is exactly what we're trying to avoid doing (because 
we can see from the ComputeCapabilitiesFilter, the extra_specs mess, and 
the giant hairball that is the NUMA and CPU pinning "metadata requests" 
how that turns out).

> 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..."
> 
> "-I

I believe I've articulated a number of times why traits should remain 
unary pieces of information, and not just said "because that's what we 
intended when we created traits".

I'm tough on this because I've seen the garbage code and unmaintainable 
mess that not having structurally sound data modeling concepts and 
information interpretation rules leads to in Nova and I don't want to 
encourage any more of it.

-jay