On Fri, 28 Sep 2018 at 22:07, melanie witt <melwi...@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 <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 > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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