Open Stack

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
> 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
>

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_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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180929/6c2d78c4/attachment.html>