<div dir="ltr">Aaaand sorry again, but due to sudden errands I won't be able to attend. Please feel free to use my bluejeans room anyway. I think my position on traits is more or less clear from previous discussions with John, Sam and Eric.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-24 18:07 GMT+02:00 Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sigh, sorry. I forgot that we're moving back to winter time this weekend. I *think* the time is 3pm UTC then. It seems to be 11am eastern US: <a href="https://www.timeanddate.com/worldclock/converter.html?iso=20171030T150000&p1=37&p2=tz_et" rel="noreferrer" target="_blank">https://www.timeanddate.com/wo<wbr>rldclock/converter.html?iso=20<wbr>171030T150000&p1=37&p2=tz_et</a>.<div class="HOEnZb"><div class="h5"><br>
<br>
On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And the winner is Mon, 30 Oct, 2pm UTC!<br>
<br>
The bluejeans ID is <a href="https://bluejeans.com/757528759" rel="noreferrer" target="_blank">https://bluejeans.com/75752875<wbr>9</a><br>
(works without plugins in recent FF and Chrome; if it asks to install an app, ignore it and look for a link saying "join with browser")<br>
<br>
On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all!<br>
<br>
I'd like to invite you to the discussion of the way to implement traits in<br>
ironic and the ironic virt driver. Please vote for the time at<br>
<a href="https://doodle.com/poll/ts43k98kkvniv8uz" rel="noreferrer" target="_blank">https://doodle.com/poll/ts43k9<wbr>8kkvniv8uz</a>. Please vote by EOD tomorrow.<br>
<br>
Note that it's going to be a technical discussion - please make sure you<br>
understand what traits are and why ironic cares about them. See below for more<br>
context.<br>
<br>
We'll probably use my bluejeans account, as it works without plugins in modern<br>
browsers. I'll post a meeting ID when we pick the date.<br>
<br>
<br>
On 10/23/2017 04:09 PM, Eric Fried wrote:<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.org<wbr>/irclogs/%23openstack-nova/%<wbr>23openstack-nova.2017-10-23.lo<wbr>g.html#t2017-10-23T13:12:13</a> <br>
<br>
On 10/23/2017 08:15 AM, Sylvain Bauza wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried <openstack@fried.cc<br>
<mailto:<a href="mailto:openstack@fried.cc" target="_blank">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" target="_blank">jaypipes@gmail.com</a><br>
      <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">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" target="_blank">openstack-dev@lists.openstack<wbr>.org</a><br>
      <mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.op<wbr>enstack.org</a>>><br>
      > *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" target="_blank">dtantsur@redhat.com</a> <mailto:<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>><br>
      > <mailto:<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a> <mailto:<a href="mailto:dtantsur@redhat.com" target="_blank">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" target="_blank">jaypipes@gmail.com</a> <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>><br>
      >     <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a> <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">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/cgit<wbr>/openstack/os-traits/tree/</a>><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</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:un<wbr>subscribe</a>><br>
      ><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:un<wbr>subscribe</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:un<wbr>subscribe</a>>><br>
      >         <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a><br>
      <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</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:un<wbr>subscribe</a>><br>
      ><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:un<wbr>subscribe</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:un<wbr>subscribe</a>>><br>
      ><br>
       <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
      <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</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:un<wbr>subscribe</a>><br>
      > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
      <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</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:un<wbr>subscribe</a>><br>
      <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
      <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote></blockquote>
<br>
</blockquote>
<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>--<br></div>-- Dmitry Tantsur<br><div>--<br></div></div></div>
</div>