<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">To add some context around what I suspect is the reason for the most recent incarnation of this debate, many Ironic users have a requirement to be able to influence the configuration of a server at deploy time, beyond the existing supported mechanisms. The classic example is hardware RAID - the ability to support workloads with different requirements is important, since if you're paying for bare metal cloud resources you'll want to make sure you're getting the most out of them. Another example that comes up is hyperthreading - often this is disabled for HPC workloads but enabled for HTC.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">We've had a plan to support deploy-time configuration that has existed for a few cycles. It began with adding support for traits [1] in Queens, and continued with the deploy steps framework [2] in Rocky. At the Stein PTG we had a lot of support [3] for finishing the job by implementing the deploy templates [4] spec that is currently in review.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">At a very high level, deploy templates allow us to map a reuired trait specified on a flavor to a set of deploy steps in ironic. These deploy steps are based on the existing cleaning steps framework that has existed in ironic for many releases, and should feel familiar to users of ironic. This scheme is conceptually quite simple, which I like.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">After a negative review on the spec from Jay on Thursday, I added a design to the alternatives section of the spec that I thought might align better with his view of the world. Essentially, decouple the scheduling and configuration - flavors may specify required traits as they can today, but also a more explicit list of names or UUIDs of ironic deploy templates. I'm still not sure how I feel about this. Architecturally it's cleaner, and is more flexible but from a usability perspective feels a little clunky.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">There was a discussion [5] in ironic's IRC yesterday that I missed, in which Jay offered to write up an alternative spec that uses glance metadata [6]. There were some concerns about adding a hard requirement on glance for the standalone use case, but we may be able to provide an alternative solution analogous to manual cleaning that fills that gap.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I'm certainly interested to see what Jay comes up with. If there is a better way of doing this, I'm all ears. That said, this is something the ironic community has been wanting for a long time now, and I can't see us waiting for a multi-cycle feature to land in nova, given that deploy templates currently requires no changes in nova.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">[1] <a href="http://specs.openstack.org/openstack/ironic-specs/specs/10.1/node-traits.html">http://specs.openstack.org/openstack/ironic-specs/specs/10.1/node-traits.html</a></div><div class="gmail_default" style="font-family:verdana,sans-serif">[2] <a href="https://specs.openstack.org/openstack/ironic-specs/specs/11.1/deployment-steps-framework.html">https://specs.openstack.org/openstack/ironic-specs/specs/11.1/deployment-steps-framework.html</a></div><div class="gmail_default" style="font-family:verdana,sans-serif">[3] <a href="https://etherpad.openstack.org/p/ironic-stein-ptg-goals">https://etherpad.openstack.org/p/ironic-stein-ptg-goals</a></div><div class="gmail_default" style="font-family:verdana,sans-serif">[4] <a href="https://review.openstack.org/#/c/504952/">https://review.openstack.org/#/c/504952/</a></div><div class="gmail_default" style="font-family:verdana,sans-serif">[5] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-09-28.log.html#t2018-09-28T14:22:57">http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-09-28.log.html#t2018-09-28T14:22:57</a></div><div class="gmail_default" style="font-family:verdana,sans-serif">[6] <a href="https://docs.openstack.org/glance/pike/user/metadefs-concepts.html">https://docs.openstack.org/glance/pike/user/metadefs-concepts.html</a></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 29 Sep 2018 at 03:15, Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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>
__________________________________________________________________________<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>