On 09/28/2018 04:42 PM, 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.
That's correct, because you're encoding >1 piece of information into the
single string (the fact that it's a temperature *and* the value of that
temperature are the two pieces of information encoded into the single
string).
Now that there's multiple pieces of information encoded in the string
the reader of the trait string needs to know how to decode those bits of
information, which is exactly what we're trying to avoid doing (because
we can see from the ComputeCapabilitiesFilter, the extra_specs mess, and
the giant hairball that is the NUMA and CPU pinning "metadata requests"
how that turns out).
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..."
"-I
I believe I've articulated a number of times why traits should remain
unary pieces of information, and not just said "because that's what we
intended when we created traits".
I'm tough on this because I've seen the garbage code and unmaintainable
mess that not having structurally sound data modeling concepts and
information interpretation rules leads to in Nova and I don't want to
encourage any more of it.
-jay
__________________________________________________________________________
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
