[openstack-dev] [placement] The "intended purpose" of traits
mark at stackhpc.com
Sat Sep 29 10:00:27 UTC 2018
On Fri, 28 Sep 2018 at 22:07, melanie witt <melwittt at gmail.com> wrote:
> 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 <openstack at 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
> >>> 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
> > "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
I think the numbers are a red herring here. RAID levels include a limited
set of combinations, of which only a handful are frequently used. It's not
the same as the temperature example, which is a continuous range of
numbers. That said, a key:value encoding could work well for RAID.
> * 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
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev