[openstack-dev] [placement] The "intended purpose" of traits
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