Ahikiro, >Thanks for the comment. We already know them as I commented >in the Summit session and ML2 weekly meeting. I'm interested in taking a look at the respective ML2 meeting. I haven't been able to find anything down to the beginning of March...
Kevin, >Have you had a chance to look at the details of our blueprint? Yes, I've fully read it. >Are there any workflows supported by yours that we forgot? Not really. Your proposal is more complete and goes towards what I had in mind as well, especially regarding the L2 Gateway use case. >We would be happy to have you help on the reference implementation for this. You can count on me ;) I'm sure we are on the right path for having a very robust and generic way to achieve heterogeneous bare metal networking working on Neutron. On 21 May 2014 18:14, Stig Telfer <[email protected]> wrote: > Our team here has been looking at something closely related that may be > of interest. There seems to be good scope for collaboration. > > > > Here’s our proposal, which includes support for bare metal networking with > the VLAN mechanism driver: > > > > https://blueprints.launchpad.net/neutron/+spec/ml2-mechanism-snmp-vlan > > > > 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. > > > > Best wishes, > > Stig Telfer > > Cray Inc. > > > > > > *From:* Russell Haering [mailto:[email protected]] > *Sent:* Tuesday, May 20, 2014 11:01 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Ironic][Neutron] - Integration with > neutron using external attachment point > > > > We've been experimenting some with how to use Neutron with Ironic here at > Rackspace. > > > > Our very experimental code: > https://github.com/rackerlabs/ironic-neutron-plugin > > > > 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. > > > > 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?". > > > > The workflow looks something like: > > > > 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. > > 2. Nova executes the "spawn" method of the Ironic virt driver, which makes > some calls to Ironic. > > 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. > > 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. > > 5. Ironic deletes a Neutron port that was created at bootstrap time to > trunk the physical switch ports for provisioning. > > 6. Ironic updates each of the customer's Neutron ports with information > about its physical switch port. > > 6. Our Neutron extension configures the switches accordingly. > > 7. Then Ironic brings the server back up. > > > > 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. > > > > 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. > > > > Thanks, > > Russell > > > > On Tue, May 20, 2014 at 7:17 AM, Akihiro Motoki <[email protected]> wrote: > > # Added [Neutron] tag as well. > > Hi Igor, > > Thanks for the comment. We already know them as I commented > in the Summit session and ML2 weekly meeting. > Kevin's blueprint now covers Ironic integration and layer2 network gateway > and I believe "campus-network" blueprint will be covered. > > We think the work can be split into generic API definition and > implementations > (including ML2). In "external attachment point" blueprint review, API > and generic topics are mainly discussed so far and the detail > implementation is not discussed > so much yet. ML2 implementation detail can be discussed later > (separately or as a part of the blueprint review). > > I am not sure what changes proposed in Blueprint [1]. > AFAIK SDN/OpenFlow controller based approach can support this, > but how can we archive this in the existing open source implementation. > I am also interested in the ML2 implementation detail. > > Anyway more input will be appreciated. > > Thanks, > Akihiro > > > On Tue, May 20, 2014 at 7:13 PM, Igor Cardoso <[email protected]> wrote: > > Hello Kevin. > > There is a similar Neutron blueprint [1], originally meant for Havana but > > now aiming for Juno. > > I would be happy to join efforts with you regarding our blueprints. > > See also: [2]. > > > > [1] https://blueprints.launchpad.net/neutron/+spec/ml2-external-port > > [2] https://blueprints.launchpad.net/neutron/+spec/campus-network > > > > > > On 19 May 2014 23:52, Kevin Benton <[email protected]> wrote: > >> > >> Hello, > >> > >> I am working on an extension for neutron to allow external attachment > >> point information to be stored and used by backend plugins/drivers to > place > >> switch ports into neutron networks[1]. > >> > >> One of the primary use cases is to integrate ironic with neutron. The > >> basic workflow is that ironic will create the external attachment points > >> when servers are initially installed. This step could either be > automated > >> (extract switch-ID and port number of LLDP message) or it could be > manually > >> performed by an admin who notes the ports a server is plugged into. > >> > >> Then when an instance is chosen for assignment and the neutron port > needs > >> to be created, the creation request would reference the corresponding > >> attachment ID and neutron would configure the physical switch port to > place > >> the port on the appropriate neutron network. > >> > >> If this workflow won't work for Ironic, please respond to this email or > >> leave comments on the blueprint review. > >> > >> 1. https://review.openstack.org/#/c/87825/ > >> > >> > >> Thanks > >> -- > >> Kevin Benton > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > -- > > Igor Duarte Cardoso. > > http://igordcard.blogspot.com > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Igor Duarte Cardoso. http://igordcard.blogspot.com
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
