<div dir="ltr">It sounds like Ironic use the Trait to configure the instance <a href="https://review.openstack.org/#/c/504952/5/specs/approved/config-template-traits.rst@95">https://review.openstack.org/#/c/504952/5/specs/approved/config-template-traits.rst@95</a><div><br></div><div>The downside I can see is that the extra burden added to the placement.</div><div>As the example, used in the spec:</div><div><div>* CUSTOM_BM_CONFIG_BIOS_VMX_ON</div><div>* CUSTOM_BM_CONFIG_BIOS_VMX_OFF</div></div><div><br></div><div>Actually, the placement only needs to find a host whose CPU have VMX feature. So it only one trait "HW_CPU_X86_VMX". But to use Trait to config the instance, we have to add each possible value as trait to the placement.</div><div><br></div><div>That isn't very terrible for the boolean value, but if there are 10 values, or it is just an integer value.</div><div><br></div><div>That sounds like we put information isn't about the scheduling to the placement, and those information adds extra burden to the placement.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-23 22:09 GMT+08:00 Eric Fried <span dir="ltr"><<a href="mailto:openstack@fried.cc" target="_blank">openstack@fried.cc</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We discussed this a little bit further in IRC [1]. We're all in<br>
agreement, but it's worth being precise on a couple of points:<br>
<br>
* We're distinguishing between a "feature" and the "trait" that<br>
represents it in placement. For the sake of this discussion, a<br>
"feature" can (maybe) be switched on or off, but a "trait" can either be<br>
present or absent on a RP.<br>
* It matters *who* can turn a feature on/off.<br>
* If it can be done by virt at spawn time, then it makes sense to have<br>
the trait on the RP, and you can switch the feature on/off via a<br>
separate extra_spec.<br>
* But if it's e.g. an admin action, and spawn has no control, then the<br>
trait needs to be *added* whenever the feature is *on*, and *removed*<br>
whenever the feature is *off*.<br>
<br>
[1]<br>
<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/irclogs/%23openstack-nova/<wbr>%23openstack-nova.2017-10-23.<wbr>log.html#t2017-10-23T13:12:13</a><br>
<span class=""><br>
On 10/23/2017 08:15 AM, Sylvain Bauza wrote:<br>
><br>
><br>
> On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried <openstack@fried.cc<br>
</span><div><div class="h5">> <mailto:<a href="mailto:openstack@fried.cc">openstack@fried.cc</a>>> wrote:<br>
><br>
> I agree with Sean. In general terms:<br>
><br>
> * A resource provider should be marked with a trait if that feature<br>
> * Can be turned on or off (whether it's currently on or not); or<br>
> * Is always on and can't ever be turned off.<br>
><br>
><br>
> No, traits are not boolean. If a resource provider stops providing a<br>
> capability, then the existing related trait should just be removed,<br>
> that's it.<br>
> If you see a trait, that's just means that the related capability for<br>
> the Resource Provider is supported, that's it too.<br>
><br>
> MHO.<br>
><br>
> -Sylvain<br>
><br>
> <br>
><br>
> * A consumer wanting that feature present (doesn't matter whether it's<br>
> on or off) should specify it as a required *trait*.<br>
> * A consumer wanting that feature present and turned on should<br>
> * Specify it as a required trait; AND<br>
> * Indicate that it be turned on via some other mechanism (e.g. a<br>
> separate extra_spec).<br>
><br>
> I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive<br>
> for placement purity.<br>
><br>
> Please invite me to the hangout or whatever.<br>
><br>
> Thanks,<br>
> Eric<br>
><br>
> On 10/23/2017 07:22 AM, Mooney, Sean K wrote:<br>
> > <br>
> ><br>
> > <br>
> ><br>
> > *From:*Jay Pipes [mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>
> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>]<br>
> > *Sent:* Monday, October 23, 2017 12:20 PM<br>
> > *To:* OpenStack Development Mailing List<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a><br>
</div></div>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>>><br>
<div><div class="h5">> > *Subject:* Re: [openstack-dev] [ironic] ironic and traits<br>
> ><br>
> > <br>
> ><br>
> > Writing from my phone... May I ask that before you proceed with any plan<br>
> > that uses traits for state information that we have a hangout or<br>
> > videoconference to discuss this? Unfortunately today and tomorrow I'm<br>
> > not able to do a hangout but I can do one on Wednesday any time of the day.<br>
> ><br>
> > <br>
> ><br>
> > */[Mooney, Sean K] on the uefi boot topic I did bring up at the<br>
> ptg that<br>
> > we wanted to standardizes tratis for “verified boot” /*<br>
> ><br>
> > */that included a trait for uefi secure boot enabled and to<br>
> indicated a<br>
> > hardware root of trust, e.g. intel boot guard or similar/*<br>
> ><br>
> > */we distinctly wanted to be able to tag nova compute hosts with those<br>
> > new traits so we could require that vms that request/*<br>
> ><br>
> > */a host with uefi secure boot enabled and a hardware root of<br>
> trust are<br>
> > scheduled only to those nodes. /*<br>
> ><br>
> > */ /*<br>
> ><br>
> > */There are many other examples that effect both vms and bare<br>
> metal such<br>
> > as, ecc/interleaved memory, cluster on die, /*<br>
> ><br>
> > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper<br>
> > threading, power states … all of these feature may be present on the<br>
> > platform/*<br>
> ><br>
> > */but I also need to know if they are turned on. Ruling out state in<br>
> > traits means all of this logic will eventually get pushed to scheduler<br>
> > filters/*<br>
> ><br>
> > */which will be suboptimal long term as more state is tracked.<br>
> Software<br>
> > defined infrastructure may be the future but hardware defined<br>
> software/*<br>
> ><br>
> > */is sadly the present…/*<br>
> ><br>
> > */ /*<br>
> ><br>
> > */I do however think there should be a sperateion between asking for a<br>
> > host that provides x with a trait and asking for x to be<br>
> configure via/*<br>
> ><br>
> > */A trait. The trait secure_boot_enabled should never result in the<br>
> > feature being enabled It should just find a host with it on. If<br>
> you want/*<br>
> ><br>
> > */To request it to be turned on you would request a host with<br>
> > secure_boot_capable as a trait and have a flavor extra spec or image<br>
> > property to request/*<br>
> ><br>
> > */Ironic to enabled it. these are two very different request and<br>
> should<br>
> > not be treated the same. /*<br>
> ><br>
> > <br>
> ><br>
> > <br>
> ><br>
> > Lemme know!<br>
> ><br>
> > -jay<br>
> ><br>
> > <br>
> ><br>
> > On Oct 23, 2017 5:01 AM, "Dmitry Tantsur" <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a> <mailto:<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>><br>
</div></div><span class="">> > <mailto:<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a> <mailto:<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>>>> wrote:<br>
> ><br>
> > Hi Jay!<br>
> ><br>
> > I appreciate your comments, but I think you're approaching the<br>
> > problem from purely VM point of view. Things simply don't work the<br>
> > same way in bare metal, at least not if we want to provide the same<br>
> > user experience.<br>
> ><br>
> > <br>
> ><br>
> > On Sun, Oct 22, 2017 at 2:25 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>><br>
</span><div><div class="h5">> > <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>>> wrote:<br>
> ><br>
> > Sorry for delay, took a week off before starting a new job.<br>
> > Comments inline.<br>
> ><br>
> > On 10/16/2017 12:24 PM, Dmitry Tantsur wrote:<br>
> ><br>
> > Hi all,<br>
> ><br>
> > I promised John to dump my thoughts on traits to the<br>
> ML, so<br>
> > here we go :)<br>
> ><br>
> > I see two roles of traits (or kinds of traits) for<br>
> bare metal:<br>
> > 1. traits that say what the node can do already (e.g. "the<br>
> > node is<br>
> > doing UEFI boot")<br>
> > 2. traits that say what the node can be *configured* to do<br>
> > (e.g. "the node can<br>
> > boot in UEFI mode")<br>
> ><br>
> ><br>
> > There's only one role for traits. #2 above. #1 is state<br>
> > information. Traits are not for state information. Traits are<br>
> > only for communicating capabilities of a resource provider<br>
> > (baremetal node).<br>
> ><br>
> > <br>
> ><br>
> > These are not different, that's what I'm talking about here. No<br>
> > users care about the difference between "this node was put in UEFI<br>
> > mode by an operator in advance", "this node was put in UEFI<br>
> mode by<br>
> > an ironic driver on demand" and "this node is always in UEFI mode,<br>
> > because it's AARCH64 and it does not have BIOS". These situation<br>
> > produce the same result (the node is booted in UEFI mode), and<br>
> thus<br>
> > it's up to ironic to hide this difference.<br>
> ><br>
> > <br>
> ><br>
> > My suggestion with traits is one way to do it, I'm not sure<br>
> what you<br>
> > suggest though.<br>
> ><br>
> > <br>
> ><br>
> ><br>
> > For example, let's say we add the following to the os-traits<br>
> > library [1]<br>
> ><br>
> > * STORAGE_RAID_0<br>
> > * STORAGE_RAID_1<br>
> > * STORAGE_RAID_5<br>
> > * STORAGE_RAID_6<br>
> > * STORAGE_RAID_10<br>
> ><br>
> > The Ironic administrator would add all RAID-related traits to<br>
> > the baremetal nodes that had the *capability* of<br>
> supporting that<br>
> > particular RAID setup [2]<br>
> ><br>
> > When provisioned, the baremetal node would either have RAID<br>
> > configured in a certain level or not configured at all.<br>
> ><br>
> ><br>
> > A very important note: the Placement API and Nova<br>
> scheduler (or<br>
> > future Ironic scheduler) doesn't care about this. At all.<br>
> I know<br>
> > it sounds like I'm being callous, but I'm not. Placement and<br>
> > scheduling doesn't care about the state of things. It only<br>
> cares<br>
> > about the capabilities of target destinations. That's it.<br>
> ><br>
> > <br>
> ><br>
> > Yes, because VMs always start with a clean state, and<br>
> hypervisor is<br>
> > there to ensure that. We don't have this luxury in ironic :) E.g.<br>
> > our SNMP driver is not even aware of boot modes (or RAID, or BIOS<br>
> > configuration), which does not mean that a node using it cannot be<br>
> > in UEFI mode (have a RAID or BIOS pre-configured, etc, etc).<br>
> ><br>
> > <br>
> ><br>
> > <br>
> ><br>
> > This seems confusing, but it's actually very useful.<br>
> Say, I<br>
> > have a flavor that<br>
> > requests UEFI boot via a trait. It will match both the<br>
> nodes<br>
> > that are already in<br>
> > UEFI mode, as well as nodes that can be put in UEFI mode.<br>
> ><br>
> ><br>
> > No :) It will only match nodes that have the UEFI capability.<br>
> > The set of providers that have the ability to be booted<br>
> via UEFI<br>
> > is *always* a superset of the set of providers that *have been<br>
> > booted via UEFI*. Placement and scheduling decisions only care<br>
> > about that superset -- the providers with a particular<br>
> capability.<br>
> ><br>
> > <br>
> ><br>
> > Well, no, it will. Again, you're purely basing on the VM idea,<br>
> where<br>
> > a VM is always *put* in UEFI mode, no matter how the hypervisor<br>
> > looks like. It is simply not the case for us. You have to care<br>
> what<br>
> > state the node is, because many drivers cannot change this state.<br>
> ><br>
> > <br>
> ><br>
> > <br>
> ><br>
> > This idea goes further with deploy templates (new concept<br>
> > we've been thinking<br>
> > about). A flavor can request something like CUSTOM_RAID_5,<br>
> > and it will match the<br>
> > nodes that already have RAID 5, or, more<br>
> interestingly, the<br>
> > nodes on which we<br>
> > can build RAID 5 before deployment. The UEFI example above<br>
> > can be treated in a<br>
> > similar way.<br>
> ><br>
> > This ends up with two sources of knowledge about traits in<br>
> > ironic:<br>
> > 1. Operators setting something they know about hardware<br>
> > ("this node is in UEFI<br>
> > mode"),<br>
> > 2. Ironic drivers reporting something they<br>
> > 2.1. know about hardware ("this node is in UEFI mode" -<br>
> > again)<br>
> > 2.2. can do about hardware ("I can put this node in<br>
> UEFI<br>
> > mode")<br>
> ><br>
> ><br>
> > You're correct that both pieces of information are important.<br>
> > However, only the "can do about hardware" part is relevant to<br>
> > Placement and Nova.<br>
> ><br>
> > For case #1 we are planning on a new CRUD API to set/unset<br>
> > traits for a node.<br>
> ><br>
> ><br>
> > I would *strongly* advise against this. Traits are not for<br>
> state<br>
> > information.<br>
> ><br>
> > Instead, consider having a DB (or JSON) schema that lists<br>
> state<br>
> > information in fields that are explicitly for that state<br>
> > information.<br>
> ><br>
> > For example, a schema that looks like this:<br>
> ><br>
> > {<br>
> > "boot": {<br>
> > "mode": <one of 'bios' or 'uefi'>,<br>
> > "params": <dict><br>
> > },<br>
> > "disk": {<br>
> > "raid": {<br>
> > "level": <int>,<br>
> > "controller": <one of 'sw' or 'hw'>,<br>
> > "driver": <string>,<br>
> > "params": <dict><br>
> > }, ...<br>
> > },<br>
> > "network": {<br>
> > ...<br>
> > }<br>
> > }<br>
> ><br>
> > etc, etc.<br>
> ><br>
> > Don't use trait strings to represent state information.<br>
> ><br>
> > <br>
> ><br>
> > I don't see an alternative proposal that will satisfy what we have<br>
> > to solve.<br>
> ><br>
> > <br>
> ><br>
> ><br>
> > Best,<br>
> > -jay<br>
> ><br>
> > Case #2 is more interesting. We have two options, I think:<br>
> ><br>
> > a) Operators still set traits on nodes, drivers are simply<br>
> > validating them. E.g.<br>
> > an operators sets CUSTOM_RAID_5, and the node's RAID<br>
> > interface checks if it is<br>
> > possible to do. The downside is obvious - with a lot of<br>
> > deploy templates<br>
> > available it can be a lot of manual work.<br>
> ><br>
> > b) Drivers report the traits, and they get somehow<br>
> added to<br>
> > the traits provided<br>
> > by an operator. Technically, there are sub-cases again:<br>
> > b.1) The new traits API returns a union of<br>
> > operator-provided and<br>
> > driver-provided traits<br>
> > b.2) The new traits API returns only operator-provided<br>
> > traits; driver-provided<br>
> > traits are returned e.g. via a new field<br>
> > (node.driver_traits). Then nova will<br>
> > have to merge the lists itself.<br>
> ><br>
> > My personal favorite is the last option: I'd like a clear<br>
> > distinction between<br>
> > different "sources" of traits, but I'd also like to reduce<br>
> > manual work for<br>
> > operators.<br>
> ><br>
> > A valid counter-argument is: what if an operator wants to<br>
> > override a<br>
> > driver-provided trait? E.g. a node can do RAID 5, but I<br>
> > don't want this<br>
> > particular node to do it for any reason. I'm not sure if<br>
> > it's a valid case, and<br>
> > what to do about it.<br>
> ><br>
> > Let me know what you think.<br>
> ><br>
> > Dmitry<br>
> ><br>
> ><br>
> > [1]<br>
> <a href="http://git.openstack.org/cgit/openstack/os-traits/tree/" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/os-traits/tree/</a><br>
> <<a href="http://git.openstack.org/cgit/openstack/os-traits/tree/" rel="noreferrer" target="_blank">http://git.openstack.org/<wbr>cgit/openstack/os-traits/tree/</a><wbr>><br>
> > [2] Based on how many attached disks the node had, the<br>
> presence<br>
> > and abilities of a hardware RAID controller, etc<br>
> ><br>
> ><br>
> ><br>
> > <br>
> _____________________________<wbr>______________________________<wbr>_______________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> > <br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> > <br>
</div></div>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-<wbr>request@lists.openstack.org?<wbr>subject:unsubscribe</a><br>
<span class="">> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>>><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
> ><br>
> > <br>
> ><br>
> ><br>
> > _____________________________<wbr>______________________________<wbr>_______________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> > <br>
</span>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-<wbr>request@lists.openstack.org?<wbr>subject:unsubscribe</a><br>
<div class="HOEnZb"><div class="h5">> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>>><br>
> > <br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
> ><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>