<div dir="ltr">Hi Zang,<div><br></div><div>As Sukhdev mentioned, we have an Arista mechanism driver in the works that covers the physical network orchestration case, and we'll send that out for review as soon as it's ready. I believe that Kyle Mestery is going to add a mechanism driver for OpenDaylight to cover the external SDN controller case.</div>
<div><br></div><div style>I think the ultimate plan is to move the logic for propagating changes to the associated compute node agents (as needed for linuxbridge/openvswitch) to mechanism drivers as well. Since the logic is working fine as is, I've been putting that off until it's truly necessary.</div>
<div style><br></div><div style>Andre</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 16, 2013 at 2:30 PM, Zang MingJie <span dir="ltr"><<a href="mailto:zealot0630@gmail.com" target="_blank">zealot0630@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 Andre:<br>
<br>
will there be any example implementation to show what and how does it<br>
work ? A smallest functional prototype with only local or flat network<br>
support will help a lot<br>
<br>
Thanks<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Jun 17, 2013 at 5:08 AM, Andre Pech <<a href="mailto:apech@aristanetworks.com">apech@aristanetworks.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I've posted an initial implementation of the ml2 mechanism driver for review<br>
> at <a href="https://review.openstack.org/33201" target="_blank">https://review.openstack.org/33201</a>. It should be in good enough shape<br>
> for others to start implementing their own mechanism drivers, though the API<br>
> is obviously still a work-in-progress and subject to change before the<br>
> Havana release. Appreciate people's review.<br>
><br>
> Thanks<br>
> Andre<br>
><br>
><br>
> On Wed, Jun 12, 2013 at 11:15 AM, Andre Pech <<a href="mailto:apech@aristanetworks.com">apech@aristanetworks.com</a>><br>
> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> Wanted to send an updated proposal based on the discussions at this<br>
>> morning's ml2 meeting. Thanks everyone for the feedback.<br>
>><br>
>> Main difference is the definitions of call that happen both within the<br>
>> transaction context and afterwards. Kyle had proposed the naming of<br>
>> appending _tx to the methods that happen within the transaction. After<br>
>> thinking about it a bit more, I ended up going with _db instead (probably<br>
>> the networking guy in me substituting tx with transmit :)). This is under<br>
>> the assumption that calls made within the transaction context are really to<br>
>> allocate resources within the database (there's not much else they can do<br>
>> given that these calls aren't supposed to block), while the non _db calls<br>
>> can then push whatever information is necessary to the outside controller /<br>
>> hardware devices, etc. Appreciate feedback on the naming.<br>
>><br>
>> Please see attached for the updated proposal. Feedback appreciated. I'll<br>
>> be working on getting these calls hooked into the ml2 plugin and will work<br>
>> to send out a review this weekend.<br>
>><br>
>> Andre<br>
>><br>
>><br>
>> On Wed, Jun 12, 2013 at 12:25 AM, Andre Pech <<a href="mailto:apech@aristanetworks.com">apech@aristanetworks.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi all,<br>
>>><br>
>>> As promised at the ml2 kickoff meeting last week, attached is our basic<br>
>>> proposal for the ml2 mechanism driver API. Sorry for the delay in getting<br>
>>> this out. We'll be on the meeting tomorrow morning and can also discuss some<br>
>>> of these points then. Assuming we agree on the direction, we'll implement<br>
>>> the backend calls from ml2 plugin and get this posted for review.<br>
>>><br>
>>> Our original proposal along these lines within the OVS Plugin (as<br>
>>> described in<br>
>>> <a href="https://blueprints.launchpad.net/quantum/+spec/ovsplugin-hardware-devices" target="_blank">https://blueprints.launchpad.net/quantum/+spec/ovsplugin-hardware-devices</a>)<br>
>>> defined a pretty specific set of methods based on our needs at the physical<br>
>>> infrastructure layer (plug_host, unplug_host) that were called based on the<br>
>>> parameters passed into the various quantum plugin methods (for example, if<br>
>>> create_port is called as part of booting the VM, then call plug_host,<br>
>>> otherwise don't).<br>
>>><br>
>>> After getting more familiar with the ml2 plugin code and looking at some<br>
>>> of the other blueprints that are looking to make use of the MechanismDriver,<br>
>>> we've instead gone with a more simple passthrough model using the existing<br>
>>> plugin language of create_network / update_network / delete_network /<br>
>>> create_port / update_port / delete_port. This makes ml2 a bit more of a<br>
>>> "meta-plugin" on top of the various mechanism drivers, but ultimately the<br>
>>> information passed to the mechanism driver really needs to be the same as<br>
>>> what is passed to the associated ml2 plugin call, just filled in with more<br>
>>> information by ml2 and the type drivers along the way. The main reason I<br>
>>> don't love using the same names is that it doesn't really help enforce the<br>
>>> distinction between plugins, type drivers, and mechanism drivers... but we<br>
>>> also failed at coming up with a distinct yet equally generic set of names<br>
>>> :). We wanted to ensure that we could handle other people's use cases and<br>
>>> not just our own, so passing in the full dict defining the network or port<br>
>>> seemed like an easy way to do this compared to what we had originally<br>
>>> proposed. If people would rather see distinct names compared to the plugin<br>
>>> and/or more restrictive and explicit parameters, that'd be fine with us too<br>
>>> and we appreciate suggestions.<br>
>>><br>
>>> One related change that may be of interest to others is<br>
>>> <a href="https://review.openstack.org/#/c/29767/" target="_blank">https://review.openstack.org/#/c/29767/</a>, which adds the hostname to the port<br>
>>> binding calls. We're also interested in getting the VM id / name passed<br>
>>> through as well in the port bindings. Bob, not sure how this fits in with<br>
>>> your modular l2 port binding blueprint<br>
>>> (<a href="https://blueprints.launchpad.net/quantum/+spec/ml2-portbinding" target="_blank">https://blueprints.launchpad.net/quantum/+spec/ml2-portbinding</a>).<br>
>>><br>
>>> One question we'd love to get feedback on - for our use case, we're only<br>
>>> going to make use of calls made within the transaction context (ie they<br>
>>> don't block and they cause a rollback on failure). Not having a good use<br>
>>> case for a mechanism driver call made outside the transaction context, we<br>
>>> haven't added any apis for this (how they're planning to be used would help<br>
>>> me name them). Anyone have any use cases for this?<br>
>>><br>
>>> Appreciate everyone's feedback. Bob, is this down the path you were<br>
>>> thinking?<br>
>>><br>
>>> Getting the backend code hooked up to make these calls in the ml2 plugin<br>
>>> is pretty trivial, so once this is settled we can have that posted for<br>
>>> review pretty quickly.<br>
>>><br>
>>> Thanks<br>
>>> Andre and Sukhdev<br>
>><br>
>><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a 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 href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a 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>