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.
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
