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

Zane Bitter zbitter at redhat.com
Fri Sep 28 15:02:24 UTC 2018

On 28/09/18 9: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. 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."

So I have no idea what traits or capabilities are (in this context), but 
I have a bit of experience with running a busy project where everyone 
wants to get their pet feature in, so I'd like to offer a couple of 
observations if I may:

* Conceptual integrity *is* important.

* 'Everything we could think of before we had a chance to try it' is not 
an especially compelling concept, and using it in place of one will tend 
to result in a lot of repeated arguments.

Both extremes ('that's how we've always done it' vs. 'free-for-all') are 
probably undesirable. I'd recommend trying to document traits in 
conceptual, rather than historical, terms. What are they good at? What 
are they not good at? Is there a limit to how many there can be while 
still remaining manageable? Are there other potential concepts that 
would map better to certain borderline use cases? That won't make the 
arguments go away, but it should help make them easier to resolve.


More information about the OpenStack-dev mailing list