<div dir="ltr"><div>Ahikiro,</div><div>>Thanks for the comment. We already know them as I commented</div><div>>in the Summit session and ML2 weekly meeting.</div><div>I'm interested in taking a look at the respective ML2 meeting.</div>
<div>I haven't been able to find anything down to the beginning of March...</div><div><br></div><div>Kevin,</div><div>>Have you had a chance to look at the details of our blueprint?</div><div>Yes, I've fully read it.</div>
<div>>Are there any workflows supported by yours that we forgot?</div><div>Not really. Your proposal is more complete and goes towards what I had</div><div>in mind as well, especially regarding the L2 Gateway use case.</div>
<div>>We would be happy to have you help on the reference implementation for this.</div><div>You can count on me ;)</div><div><br></div><div>I'm sure we are on the right path for having a very robust and generic way</div>
<div>to achieve heterogeneous bare metal networking working on Neutron.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 May 2014 18:14, Stig Telfer <span dir="ltr"><<a href="mailto:stelfer@cray.com" target="_blank">stelfer@cray.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Our team here has been looking at something closely related that may be of interest. There seems to be good scope for collaboration.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Here’s our proposal, which includes support for bare metal networking with the VLAN mechanism driver:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="https://blueprints.launchpad.net/neutron/+spec/ml2-mechanism-snmp-vlan" target="_blank">https://blueprints.launchpad.net/neutron/+spec/ml2-mechanism-snmp-vlan</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Our project is a point solution at your step 6. The rest of the workflow looks complimentary and solves the unanswered questions in our bp proposal. As indeed
would the neutron-external-ports spec.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Best wishes,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Stig Telfer<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Cray Inc.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Russell Haering [mailto:<a href="mailto:russellhaering@gmail.com" target="_blank">russellhaering@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, May 20, 2014 11:01 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Ironic][Neutron] - Integration with neutron using external attachment point<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">We've been experimenting some with how to use Neutron with Ironic here at Rackspace.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Our very experimental code: <a href="https://github.com/rackerlabs/ironic-neutron-plugin" target="_blank">https://github.com/rackerlabs/ironic-neutron-plugin</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Our objective is the same as what you're describing, to allow Nova servers backed by Ironic to attach to arbitrary Neutron networks. We're initially targeting VLAN-based networks only, but eventually want to do VXLAN from the top-of-rack
switches, controlled via an SDN controller.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Our approach is a little different than what you're describing though. Our objective is to modify the existing Nova -> Neutron interaction as little as possible, which means approaching the problem by thinking "how would an L2 agent do
this?".<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The workflow looks something like:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1. Nova calls Neutron to create a virtual "port". Because this happens _before_ Nova touches the virt driver, the port is at this point identical to one created for a virtual server.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2. Nova executes the "spawn" method of the Ironic virt driver, which makes some calls to Ironic.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">3. Inside Ironic, we know about the physical switch ports that the selected Node is connected to. This information is discovered early-on using LLDP and stored in the Ironic database.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">4. We actually need the node to remain on an internal provisioning VLAN for most of the provisioning process, but once we're done with on-host work we turn the server off.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">5. Ironic deletes a Neutron port that was created at bootstrap time to trunk the physical switch ports for provisioning.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">6. Ironic updates each of the customer's Neutron ports with information about its physical switch port.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">6. Our Neutron extension configures the switches accordingly.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">7. Then Ironic brings the server back up.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The destroy process basically does the reverse. Ironic removes the physical switch mapping from the Neutron ports, re-creates an internal trunked port, does some work to tear down the server, then passes control back to Nova. At that point
Nova can do what it wants with the Neutron ports. Hypothetically that could include allocating them to a different Ironic Node, etc, although in practice it just deletes them.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Again, this is all very experimental in nature, but it seems to work fairly well for the use-cases we've considered. We'd love to find a way to collaborate with others working on similar problems.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Russell<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, May 20, 2014 at 7:17 AM, Akihiro Motoki <<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal"># Added [Neutron] tag as well.<br>
<br>
Hi Igor,<br>
<br>
Thanks for the comment. We already know them as I commented<br>
in the Summit session and ML2 weekly meeting.<br>
Kevin's blueprint now covers Ironic integration and layer2 network gateway<br>
and I believe "campus-network" blueprint will be covered.<br>
<br>
We think the work can be split into generic API definition and implementations<br>
(including ML2). In "external attachment point" blueprint review, API<br>
and generic topics are mainly discussed so far and the detail<br>
implementation is not discussed<br>
so much yet. ML2 implementation detail can be discussed later<br>
(separately or as a part of the blueprint review).<br>
<br>
I am not sure what changes proposed in Blueprint [1].<br>
AFAIK SDN/OpenFlow controller based approach can support this,<br>
but how can we archive this in the existing open source implementation.<br>
I am also interested in the ML2 implementation detail.<br>
<br>
Anyway more input will be appreciated.<br>
<br>
Thanks,<br>
Akihiro<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
On Tue, May 20, 2014 at 7:13 PM, Igor Cardoso <<a href="mailto:igordcard@gmail.com" target="_blank">igordcard@gmail.com</a>> wrote:<br>
> Hello Kevin.<br>
> There is a similar Neutron blueprint [1], originally meant for Havana but<br>
> now aiming for Juno.<br>
> I would be happy to join efforts with you regarding our blueprints.<br>
> See also: [2].<br>
><br>
> [1] <a href="https://blueprints.launchpad.net/neutron/+spec/ml2-external-port" target="_blank">
https://blueprints.launchpad.net/neutron/+spec/ml2-external-port</a><br>
> [2] <a href="https://blueprints.launchpad.net/neutron/+spec/campus-network" target="_blank">
https://blueprints.launchpad.net/neutron/+spec/campus-network</a><br>
><br>
><br>
> On 19 May 2014 23:52, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> I am working on an extension for neutron to allow external attachment<br>
>> point information to be stored and used by backend plugins/drivers to place<br>
>> switch ports into neutron networks[1].<br>
>><br>
>> One of the primary use cases is to integrate ironic with neutron. The<br>
>> basic workflow is that ironic will create the external attachment points<br>
>> when servers are initially installed. This step could either be automated<br>
>> (extract switch-ID and port number of LLDP message) or it could be manually<br>
>> performed by an admin who notes the ports a server is plugged into.<br>
>><br>
>> Then when an instance is chosen for assignment and the neutron port needs<br>
>> to be created, the creation request would reference the corresponding<br>
>> attachment ID and neutron would configure the physical switch port to place<br>
>> the port on the appropriate neutron network.<br>
>><br>
>> If this workflow won't work for Ironic, please respond to this email or<br>
>> leave comments on the blueprint review.<br>
>><br>
>> 1. <a href="https://review.openstack.org/#/c/87825/" target="_blank">https://review.openstack.org/#/c/87825/</a><br>
>><br>
>><br>
>> Thanks<br>
>> --<br>
>> Kevin Benton<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
><br>
> --<br>
> Igor Duarte Cardoso.<br>
> <a href="http://igordcard.blogspot.com" target="_blank">http://igordcard.blogspot.com</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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" target="_blank">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><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</div>
<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Igor Duarte Cardoso.</div><a href="http://igordcard.blogspot.com" target="_blank">http://igordcard.blogspot.com</a><br></div>
</div>