<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 28 Sep 2018 at 22:07, melanie witt <<a href="mailto:melwittt@gmail.com">melwittt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 28 Sep 2018 15:42:23 -0500, Eric Fried wrote:<br>
> On 09/28/2018 09:41 AM, Balázs Gibizer wrote:<br>
>><br>
>><br>
>> On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried <openstack@fried.cc> wrote:<br>
>>> It's time somebody said this.<br>
>>><br>
>>> Every time we turn a corner or look under a rug, we find another use<br>
>>> case for provider traits in placement. But every time we have to have<br>
>>> the argument about whether that use case satisfies the original<br>
>>> "intended purpose" of traits.<br>
>>><br>
>>> That's only reason I've ever been able to glean: that it (whatever "it"<br>
>>> is) wasn't what the architects had in mind when they came up with the<br>
>>> idea of traits. We're not even talking about anything that would require<br>
>>> changes to the placement API. Just, "Oh, that's not a *capability* -<br>
>>> shut it down."<br>
>>><br>
>>> Bubble wrap was originally intended as a textured wallpaper and a<br>
>>> greenhouse insulator. Can we accept the fact that traits have (many,<br>
>>> many) uses beyond marking capabilities, and quit with the arbitrary<br>
>>> restrictions?<br>
>><br>
>> How far are we willing to go? Does an arbitrary (key: value) pair<br>
>> encoded in a trait name like key_`str(value)` (e.g. CURRENT_TEMPERATURE:<br>
>> 85 encoded as CUSTOM_TEMPERATURE_85) something we would be OK to see in<br>
>> placement?<br>
> <br>
> Great question. Perhaps TEMPERATURE_DANGEROUSLY_HIGH is okay, but<br>
> TEMPERATURE_<specific_number> is not. This thread isn't about setting<br>
> these parameters; it's about getting us to a point where we can discuss<br>
> a question just like this one without running up against:<br>
> <br>
> "That's a hard no, because you shouldn't encode key/value pairs in traits."<br>
> <br>
> "Oh, why's that?"<br>
> <br>
> "Because that's not what we intended when we created traits."<br>
> <br>
> "But it would work, and the alternatives are way harder."<br>
> <br>
> "-1"<br>
> <br>
> "But..."<br>
> <br>
> "-1"<br>
I think it's not so much about the intention when traits were created <br>
and more about what UX callers of the API are left with, if we were to <br>
recommend representing everything with traits and not providing another <br>
API for key-value use cases. We need to think about what the maintenance <br>
of their deployments will look like if traits are the only tool we provide.<br>
<br>
I get that we don't want to put artificial restrictions on how API <br>
callers can and can't use the traits API, but will they be left with a <br>
manageable experience if that's all that's available?<br>
<br>
I don't have time right now to come up with a really great example, but <br>
I'm thinking along the lines of, can this get out of hand (a la "flavor <br>
explosion") for an operator using traits to model what their compute <br>
hosts can do?<br>
<br>
Please forgive the oversimplified example I'm going to try to use to <br>
illustrate my concern:<br>
<br>
We all agree we can have traits for resource providers like:<br>
<br>
* HAS_SSD<br>
* HAS_GPU<br>
* HAS_WINDOWS<br>
<br>
But things get less straightforward when we think of traits like:<br>
<br>
* HAS_OWNER_CINDER<br>
* HAS_OWNER_NEUTRON<br>
* HAS_OWNER_CYBORG<br>
* HAS_RAID_0<br>
* HAS_RAID_1<br>
* HAS_RAID_5<br>
* HAS_RAID_6<br>
* HAS_RAID_10<br></blockquote><div> </div><div><span class="gmail_default" style="font-family:verdana,sans-serif">I think the numbers are a </span> <span class="gmail_default" style="font-family:verdana,sans-serif">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.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* HAS_NUMA_CELL_0<br>
* HAS_NUMA_CELL_1<br>
* HAS_NUMA_CELL_2<br>
* HAS_NUMA_CELL_3<br>
<br>
I'm concerned about a lot of repetition here and maintenance headache <br>
for operators. That's where the thoughts about whether we should provide <br>
something like a key-value construct to API callers where they can <br>
instead say:<br>
<br>
* OWNER=CINDER<br>
* RAID=10<br>
* NUMA_CELL=0<br>
<br>
for each resource provider.<br>
<br>
If I'm off base with my example, please let me know. I'm not a placement <br>
expert.<br>
<br>
Anyway, I hope that gives an idea of what I'm thinking about in this <br>
discussion. I agree we need to pick a direction and go with it. I'm just <br>
trying to look out for the experience operators are going to be using <br>
this and maintaining it in their deployments.<br>
<br>
Cheers,<br>
-melanie<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>