<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>