On Fri, 28 Sep 2018 15:42:23 -0500, 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 <openst...@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"
I think it's not so much about the intention when traits were created
and more about what UX callers of the API are left with, if we were to
recommend representing everything with traits and not providing another
API for key-value use cases. We need to think about what the maintenance
of their deployments will look like if traits are the only tool we provide.
I get that we don't want to put artificial restrictions on how API
callers can and can't use the traits API, but will they be left with a
manageable experience if that's all that's available?
I don't have time right now to come up with a really great example, but
I'm thinking along the lines of, can this get out of hand (a la "flavor
explosion") for an operator using traits to model what their compute
hosts can do?
Please forgive the oversimplified example I'm going to try to use to
illustrate my concern:
We all agree we can have traits for resource providers like:
* HAS_SSD
* HAS_GPU
* HAS_WINDOWS
But things get less straightforward when we think of traits like:
* HAS_OWNER_CINDER
* HAS_OWNER_NEUTRON
* HAS_OWNER_CYBORG
* HAS_RAID_0
* HAS_RAID_1
* HAS_RAID_5
* HAS_RAID_6
* HAS_RAID_10
* HAS_NUMA_CELL_0
* HAS_NUMA_CELL_1
* HAS_NUMA_CELL_2
* HAS_NUMA_CELL_3
I'm concerned about a lot of repetition here and maintenance headache
for operators. That's where the thoughts about whether we should provide
something like a key-value construct to API callers where they can
instead say:
* OWNER=CINDER
* RAID=10
* NUMA_CELL=0
for each resource provider.
If I'm off base with my example, please let me know. I'm not a placement
expert.
Anyway, I hope that gives an idea of what I'm thinking about in this
discussion. I agree we need to pick a direction and go with it. I'm just
trying to look out for the experience operators are going to be using
this and maintaining it in their deployments.
Cheers,
-melanie
__________________________________________________________________________
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
