[openstack-dev] [placement] The "intended purpose" of traits

Eric Fried openstack at fried.cc
Fri Sep 28 20:42:23 UTC 2018



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"

> 
> Cheers,
> gibi
> 
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list