<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 3/18/14, 3:04 PM, racha wrote:<br>
    </div>
    <blockquote
cite="mid:CAJ7n72x1uUQVc0xc_J+9zbpusOcukVtkgfHjRZj4kO9kNw1CRw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Hi
          Mathieu,</div>
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"> 
           Sorry I wasn't following the recent progress on ML2, and I
          was effectively missing the right abstractions of all MDs in
          my out of topic questions.</div>
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">If
          I understand correctly, there will be no priority between all
          MDs binding the same port, but an optional "port filter" could
          also be used so that the first responding MD matching the
          filter will assign itself.</div>
      </div>
    </blockquote>
    Hi Racha,<br>
    <br>
    The bug fix Mathieu referred to below that I am working on will move
    the attempt to bind outside the DB transaction that triggered the
    [re]binding, and thus will involve a separate DB transaction to
    commit the result of the binding. But the basic algorithm for
    binding ports will not be changing as part of this fix. The
    bind_port() method is called sequentially on each mechanism driver
    in the order they are listed in the mechanism_drivers config
    variable, until one succeeds in binding the port, or all have failed
    to bind the port. Since this will now be happening outside a DB
    transaction, its possible that more than one thread could
    simultaneously try to bind the same port, and this concurrency is
    handled by having all such threads use the result that gets
    committed first.<br>
    <br>
    -Bob<br>
    <br>
    <blockquote
cite="mid:CAJ7n72x1uUQVc0xc_J+9zbpusOcukVtkgfHjRZj4kO9kNw1CRw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"><br>
        </div>
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Thanks
          for your answer.</div>
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"><br>
        </div>
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Best
          Regards,</div>
        <div class="gmail_default"
          style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">
          Racha</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Mon, Mar 17, 2014 at 3:17 AM,
          Mathieu Rohon <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi racha,<br>
            <br>
            I don't think your topic has something to deal with Nader's
            topics.<br>
            Please, create another topic, it would be easier to follow.<br>
            FYI, robert kukura is currently refactoring the MD binding,
            please<br>
            have a look here : <a moz-do-not-send="true"
              href="https://bugs.launchpad.net/neutron/+bug/1276391"
              target="_blank">https://bugs.launchpad.net/neutron/+bug/1276391</a>.
            As<br>
            i understand, there won't be priority between MD that can
            bind a same<br>
            port. The first that will respond to the binding request
            will give its<br>
            vif_type.<br>
            <br>
            Best,<br>
            <br>
            Mathieu<br>
            <div>
              <div class="h5"><br>
                On Fri, Mar 14, 2014 at 8:14 PM, racha <<a
                  moz-do-not-send="true" href="mailto:benali@gmail.com">benali@gmail.com</a>>
                wrote:<br>
                > Hi,<br>
                >       Is it possible (in the latest upstream) to
                partition the same<br>
                > integration bridge "br-int" into multiple isolated
                partitions (in terms of<br>
                > lvids ranges, patch ports, etc.) between OVS
                mechanism driver and ODL<br>
                > mechanism driver? And then how can we pass some
                details to Neutron API (as<br>
                > in the provider segmentation type/id/etc) so that
                ML2 assigns a mechanism<br>
                > driver to the virtual network? The other
                alternative I guess is to create<br>
                > another integration bridge managed by a different
                Neutron instance? Probably<br>
                > I am missing something.<br>
                ><br>
                > Best Regards,<br>
                > Racha<br>
                ><br>
                ><br>
                > On Fri, Mar 7, 2014 at 10:33 AM, Nader Lahouti <<a
                  moz-do-not-send="true"
                  href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
                > wrote:<br>
                >><br>
                >> 1) Does it mean an interim solution is to have
                our own plugin (and have<br>
                >> all the changes in it) and declare it as
                core_plugin instead of Ml2Plugin?<br>
                >><br>
                >> 2) The other issue as I mentioned before, is
                that the extension(s) is not<br>
                >> showing up in the result, for instance when
                create_network is called<br>
                >> [result = super(Ml2Plugin,
                self).create_network(context, network)], and as<br>
                >> a result they cannot be used in the mechanism
                drivers when needed.<br>
                >><br>
                >> Looks like the process_extensions is disabled
                when fix for Bug 1201957<br>
                >> committed and here is the change:<br>
                >> Any idea why it is disabled?<br>
                >><br>
                >> ----------<br>
                >> Avoid performing extra query for fetching port
                security binding<br>
                >><br>
                >> Bug 1201957<br>
                >><br>
                >><br>
                >> Add a relationship performing eager load in
                Port and Network<br>
                >><br>
                >> models, thus preventing the 'extend' function
                from performing<br>
                >><br>
                >> an extra database query.<br>
                >><br>
                >> Also fixes a comment in securitygroups_db.py<br>
                >><br>
                >><br>
                >> Change-Id:
                If0f0277191884aab4dcb1ee36826df7f7d66a8fa<br>
                >><br>
                >>  master   h.1<br>
                >><br>
              </div>
            </div>
            >> ...<br>
            <div class="HOEnZb">
              <div class="h5">>><br>
                >>  2013.2<br>
                >><br>
                >> commit f581b2faf11b49852b0e1d6f2ddd8d19b8b69cdf
                1 parent ca421e7<br>
                >><br>
                >> Salvatore Orlando salv-orlando authored 8
                months ago<br>
                >><br>
                >><br>
                >> 2  neutron/db/db_base_plugin_v2.py View<br>
                >><br>
                >>  @@ -995,7 +995,7 @@ def create_network(self,
                context, network):<br>
                >><br>
                >> 995           'status':
                constants.NET_STATUS_ACTIVE}<br>
                >><br>
                >> 996   network = models_v2.Network(**args)<br>
                >><br>
                >> 997   context.session.add(network)<br>
                >><br>
                >> 998 -        return
                self._make_network_dict(network)<br>
                >><br>
                >> 998 +        return
                self._make_network_dict(network,<br>
                >> process_extensions=False)<br>
                >><br>
                >> 999<br>
                >><br>
                >> 1000  def update_network(self, context, id,
                network):<br>
                >><br>
                >> 1001<br>
                >><br>
                >>          n = network['network']<br>
                >><br>
                >><br>
                >> -----------------------<br>
                >><br>
                >><br>
                >> Regards,<br>
                >> Nader.<br>
                >><br>
                >><br>
                >><br>
                >><br>
                >><br>
                >> On Fri, Mar 7, 2014 at 6:26 AM, Robert Kukura
                <<a moz-do-not-send="true"
                  href="mailto:kukura@noironetworks.com">kukura@noironetworks.com</a>><br>
                >> wrote:<br>
                >>><br>
                >>><br>
                >>> On 3/7/14, 3:53 AM, Édouard Thuleau wrote:<br>
                >>><br>
                >>> Yes, that sounds good to be able to load
                extensions from a mechanism<br>
                >>> driver.<br>
                >>><br>
                >>> But another problem I think we have with
                ML2 plugin is the list<br>
                >>> extensions supported by default [1].<br>
                >>> The extensions should only load by MD and
                the ML2 plugin should only<br>
                >>> implement the Neutron core API.<br>
                >>><br>
                >>><br>
                >>> Keep in mind that ML2 supports multiple MDs
                simultaneously, so no single<br>
                >>> MD can really control what set of
                extensions are active. Drivers need to be<br>
                >>> able to load private extensions that only
                pertain to that driver, but we<br>
                >>> also need to be able to share common
                extensions across subsets of drivers.<br>
                >>> Furthermore, the semantics of the
                extensions need to be correct in the face<br>
                >>> of multiple co-existing drivers, some of
                which know about the extension, and<br>
                >>> some of which don't. Getting this properly
                defined and implemented seems<br>
                >>> like a good goal for juno.<br>
                >>><br>
                >>> -Bob<br>
                >>><br>
                >>><br>
                >>><br>
                >>> Any though ?<br>
                >>> Édouard.<br>
                >>><br>
                >>> [1]<br>
                >>> <a moz-do-not-send="true"
href="https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L87"
                  target="_blank">https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L87</a><br>
                >>><br>
                >>><br>
                >>><br>
                >>> On Fri, Mar 7, 2014 at 8:32 AM, Akihiro
                Motoki <<a moz-do-not-send="true"
                  href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>>
                wrote:<br>
                >>>><br>
                >>>> Hi,<br>
                >>>><br>
                >>>> I think it is better to continue the
                discussion here. It is a good log<br>
                >>>> :-)<br>
                >>>><br>
                >>>> Eugine and I talked the related topic
                to allow drivers to load<br>
                >>>> extensions)  in Icehouse Summit<br>
                >>>> but I could not have enough time to
                work on it during Icehouse.<br>
                >>>> I am still interested in implementing
                it and will register a blueprint<br>
                >>>> on it.<br>
                >>>><br>
                >>>> etherpad in icehouse summit has
                baseline thought on how to achieve it.<br>
                >>>> <a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/icehouse-neutron-vendor-extension"
                  target="_blank">https://etherpad.openstack.org/p/icehouse-neutron-vendor-extension</a><br>
                >>>> I hope it is a good start point of the
                discussion.<br>
                >>>><br>
                >>>> Thanks,<br>
                >>>> Akihiro<br>
                >>>><br>
                >>>> On Fri, Mar 7, 2014 at 4:07 PM, Nader
                Lahouti <<a moz-do-not-send="true"
                  href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
                >>>> wrote:<br>
                >>>> > Hi Kyle,<br>
                >>>> ><br>
                >>>> > Just wanted to clarify: Should I
                continue using this mailing list to<br>
                >>>> > post my<br>
                >>>> > question/concerns about ML2?
                Please advise.<br>
                >>>> ><br>
                >>>> > Thanks,<br>
                >>>> > Nader.<br>
                >>>> ><br>
                >>>> ><br>
                >>>> ><br>
                >>>> > On Thu, Mar 6, 2014 at 1:50 PM,
                Kyle Mestery<br>
                >>>> > <<a moz-do-not-send="true"
                  href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>><br>
                >>>> > wrote:<br>
                >>>> >><br>
                >>>> >> Thanks Edgar, I think this is
                the appropriate place to continue this<br>
                >>>> >> discussion.<br>
                >>>> >><br>
                >>>> >><br>
                >>>> >> On Thu, Mar 6, 2014 at 2:52
                PM, Edgar Magana <<a moz-do-not-send="true"
                  href="mailto:emagana@plumgrid.com">emagana@plumgrid.com</a>><br>
                >>>> >> wrote:<br>
                >>>> >>><br>
                >>>> >>> Nader,<br>
                >>>> >>><br>
                >>>> >>> I would encourage you to
                first discuss the possible extension with<br>
                >>>> >>> the<br>
                >>>> >>> ML2 team. Rober and Kyle
                are leading this effort and they have a IRC<br>
                >>>> >>> meeting<br>
                >>>> >>> every week:<br>
                >>>> >>><br>
                >>>> >>> <a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting"
                  target="_blank">https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting</a><br>
                >>>> >>><br>
                >>>> >>> Bring your concerns on
                this meeting and get the right feedback.<br>
                >>>> >>><br>
                >>>> >>> Thanks,<br>
                >>>> >>><br>
                >>>> >>> Edgar<br>
                >>>> >>><br>
                >>>> >>> From: Nader Lahouti <<a
                  moz-do-not-send="true"
                  href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
                >>>> >>> Reply-To: OpenStack List
                <<a moz-do-not-send="true"
                  href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
                >>>> >>> Date: Thursday, March 6,
                2014 12:14 PM<br>
                >>>> >>> To: OpenStack List <<a
                  moz-do-not-send="true"
                  href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
                >>>> >>> Subject: Re:
                [openstack-dev] [Neutron][ML2]<br>
                >>>> >>><br>
                >>>> >>> Hi Aaron,<br>
                >>>> >>><br>
                >>>> >>> I appreciate your reply.<br>
                >>>> >>><br>
                >>>> >>> Here is some more details
                on what I'm trying to do:<br>
                >>>> >>> I need to add new
                attribute to the network resource using extensions<br>
                >>>> >>> (i.e. network config
                profile) and use it in the mechanism driver (in<br>
                >>>> >>> the<br>
                >>>> >>>
                create_network_precommit/postcommit).<br>
                >>>> >>> If I use current
                implementation of Ml2Plugin, when a call is made to<br>
                >>>> >>> mechanism driver's
                create_network_precommit/postcommit the new<br>
                >>>> >>> attribute is<br>
                >>>> >>> not included in the
                'mech_context'<br>
                >>>> >>> Here is code from
                Ml2Plugin:<br>
                >>>> >>> class Ml2Plugin(...):<br>
                >>>> >>> ...<br>
                >>>> >>>        def
                create_network(self, context, network):<br>
                >>>> >>>             net_data =
                network['network']<br>
                >>>> >>> ...<br>
                >>>> >>>         with
                session.begin(subtransactions=True):<br>
                >>>> >>>            
                self._ensure_default_security_group(context, tenant_id)<br>
                >>>> >>>             result =
                super(Ml2Plugin, self).create_network(context,<br>
                >>>> >>> network)<br>
                >>>> >>>             network_id =
                result['id']<br>
                >>>> >>> ...<br>
                >>>> >>>             mech_context =
                driver_context.NetworkContext(self,<br>
                >>>> >>> context,<br>
                >>>> >>> result)<br>
                >>>> >>><br>
                >>>> >>>
                self.mechanism_manager.create_network_precommit(mech_context)<br>
                >>>> >>><br>
                >>>> >>> Also need to include new
                extension in the<br>
                >>>> >>>
                _supported_extension_aliases.<br>
                >>>> >>><br>
                >>>> >>> So to avoid changes in the
                existing code, I was going to create my<br>
                >>>> >>> own<br>
                >>>> >>> plugin (which will be very
                similar to Ml2Plugin) and use it as<br>
                >>>> >>> core_plugin.<br>
                >>>> >>><br>
                >>>> >>> Please advise the right
                solution implementing that.<br>
                >>>> >>><br>
                >>>> >>> Regards,<br>
                >>>> >>> Nader.<br>
                >>>> >>><br>
                >>>> >>><br>
                >>>> >>> On Wed, Mar 5, 2014 at
                11:49 PM, Aaron Rosen <<a moz-do-not-send="true"
                  href="mailto:aaronorosen@gmail.com">aaronorosen@gmail.com</a>><br>
                >>>> >>> wrote:<br>
                >>>> >>>><br>
                >>>> >>>> Hi Nader,<br>
                >>>> >>>><br>
                >>>> >>>> Devstack's default
                plugin is ML2. Usually you wouldn't 'inherit'<br>
                >>>> >>>> one<br>
                >>>> >>>> plugin in another. I'm
                guessing  you probably wire a driver that<br>
                >>>> >>>> ML2 can use<br>
                >>>> >>>> though it's hard to
                tell from the information you've provided what<br>
                >>>> >>>> you're<br>
                >>>> >>>> trying to do.<br>
                >>>> >>>><br>
                >>>> >>>> Best,<br>
                >>>> >>>><br>
                >>>> >>>> Aaron<br>
                >>>> >>>><br>
                >>>> >>>><br>
                >>>> >>>> On Wed, Mar 5, 2014 at
                10:42 PM, Nader Lahouti<br>
                >>>> >>>> <<a
                  moz-do-not-send="true"
                  href="mailto:nader.lahouti@gmail.com">nader.lahouti@gmail.com</a>><br>
                >>>> >>>> wrote:<br>
                >>>> >>>>><br>
                >>>> >>>>> Hi All,<br>
                >>>> >>>>><br>
                >>>> >>>>> I have a question
                regarding ML2 plugin in neutron:<br>
                >>>> >>>>> My understanding
                is that, 'Ml2Plugin' is the default core_plugin<br>
                >>>> >>>>> for<br>
                >>>> >>>>> neutron ML2. We
                can use either the default plugin or our own<br>
                >>>> >>>>> plugin (i.e.<br>
                >>>> >>>>> my_ml2_core_plugin
                that can be inherited from Ml2Plugin) and use<br>
                >>>> >>>>> it as<br>
                >>>> >>>>> core_plugin.<br>
                >>>> >>>>><br>
                >>>> >>>>> Is my
                understanding correct?<br>
                >>>> >>>>><br>
                >>>> >>>>><br>
                >>>> >>>>> Regards,<br>
                >>>> >>>>> Nader.<br>
                >>>> >>>>><br>
                >>>> >>>>>
                _______________________________________________<br>
                >>>> >>>>> OpenStack-dev
                mailing list<br>
                >>>> >>>>> <a
                  moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> >>>>> <a
                  moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>> >>>>><br>
                >>>> >>>><br>
                >>>> >>>><br>
                >>>> >>>>
                _______________________________________________<br>
                >>>> >>>> OpenStack-dev mailing
                list<br>
                >>>> >>>> <a
                  moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> >>>> <a
                  moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>> >>>><br>
                >>>> >>><br>
                >>>> >>>
                _______________________________________________
                OpenStack-dev<br>
                >>>> >>> mailing<br>
                >>>> >>> list <a
                  moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> >>> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>> >>><br>
                >>>> >>>
                _______________________________________________<br>
                >>>> >>> OpenStack-dev mailing list<br>
                >>>> >>> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> >>> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>> >>><br>
                >>>> >><br>
                >>>> >><br>
                >>>> >>
                _______________________________________________<br>
                >>>> >> OpenStack-dev mailing list<br>
                >>>> >> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> >> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>> >><br>
                >>>> ><br>
                >>>> ><br>
                >>>> >
                _______________________________________________<br>
                >>>> > OpenStack-dev mailing list<br>
                >>>> > <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> > <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>> ><br>
                >>>><br>
                >>>>
                _______________________________________________<br>
                >>>> OpenStack-dev mailing list<br>
                >>>> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>><br>
                >>><br>
                >>><br>
                >>><br>
                >>>
                _______________________________________________<br>
                >>> OpenStack-dev mailing list<br>
                >>> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>><br>
                >>><br>
                >>><br>
                >>>
                _______________________________________________<br>
                >>> OpenStack-dev mailing list<br>
                >>> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>><br>
                >><br>
                >><br>
                >> _______________________________________________<br>
                >> OpenStack-dev mailing list<br>
                >> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >><br>
                ><br>
                ><br>
                > _______________________________________________<br>
                > OpenStack-dev mailing list<br>
                > <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                > <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                ><br>
                <br>
                _______________________________________________<br>
                OpenStack-dev mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>