<div dir="ltr">Sorry for append another email for something I missed to say.<br><br><div class="gmail_quote"><div dir="ltr">Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> 于2018年9月29日周六 上午10:01写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> 于2018年9月29日周六 上午5:51写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/28/2018 04:42 PM, Eric Fried wrote:<br>
> On 09/28/2018 09:41 AM, Balázs Gibizer wrote:<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.<br>
<br>
That's correct, because you're encoding >1 piece of information into the <br>
single string (the fact that it's a temperature *and* the value of that <br>
temperature are the two pieces of information encoded into the single <br>
string).<br>
<br>
Now that there's multiple pieces of information encoded in the string <br>
the reader of the trait string needs to know how to decode those bits of <br>
information, which is exactly what we're trying to avoid doing (because <br>
we can see from the ComputeCapabilitiesFilter, the extra_specs mess, and <br>
the giant hairball that is the NUMA and CPU pinning "metadata requests" <br>
how that turns out).<br></blockquote><div><br></div><div>May I understand the one of Jay's complain is about metadata API undiscoverable? That is extra_spec mess and ComputeCapabilitiesFilter mess?</div></div></div></blockquote><div><br></div><div>If yes, then we resolve the discoverable by the "/Traits" API.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Another complain is about the information in the string. Agree with that TEMPERATURE_<specific_number> is terriable.</div><div>I prefer the way I used in nvdimm proposal now, I don't want to use Trait NVDIMM_DEVICE_500GB, NVDIMM_DEVICE_1024GB. I want to put them into the different resource provider, and use min_size, max_size limit the allocation. And the user will request with resource class like RC_NVDIMM_GB=512.</div></div></div></blockquote><div><br></div><div>TEMPERATURE_<specific_number> is wrong, as the way using it. But I don't thing the version of BIOS is wrong, I don't expect the end user to ready the information from the trait directly, there should document from the admin to explain more. The version of BIOS should be a thing understand by the admin, then it is enough.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> This thread isn't about setting these parameters; it's about getting<br>
> us to a point where we can discuss a question just like this one<br>
> without running up against: ><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>
> "-I<br>
<br>
I believe I've articulated a number of times why traits should remain <br>
unary pieces of information, and not just said "because that's what we <br>
intended when we created traits".<br>
<br>
I'm tough on this because I've seen the garbage code and unmaintainable <br>
mess that not having structurally sound data modeling concepts and <br>
information interpretation rules leads to in Nova and I don't want to <br>
encourage any more of it.<br>
<br>
-jay<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>
</blockquote></div></div>