16:02:05 <Sukhdev> #startmeeting networking_ml2
16:02:05 <openstack> Meeting started Wed Apr 29 16:02:05 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:09 <openstack> The meeting name has been set to 'networking_ml2'
16:02:19 <Sukhdev> #topic: Agenda
16:02:23 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Agenda
16:02:40 <Sukhdev> #Announcements:
16:02:51 <Sukhdev> #topic: Announcements
16:02:59 <Sukhdev> :-) still sleepy :-)
16:03:15 <Sukhdev> Kilo is almost ready to go -
16:03:47 <Sukhdev> Do know if folks noticed that the spec submittal process for Liberty is being changed -
16:03:54 <Sukhdev> it is much simpler process
16:04:08 <Sukhdev> see here - https://review.openstack.org/#/c/177342/
16:04:40 <Sukhdev> Another thing - there is a slight change in the drivers team
16:04:58 <Sukhdev> salvatore and Mark are being replaced with Maru and Doug
16:05:12 <Sukhdev> That is all I have
16:05:25 <Sukhdev> Does anybody have any other announcement?
16:05:34 <Sukhdev> or any gossip?
16:05:35 <egon> Gotta love all the vendor CIs weighing in on that review.
16:06:10 <Sukhdev> egon: :-)
16:06:14 <shivharis> egon: :-)
16:06:54 <Sukhdev> If nothing else, lets move on
16:07:03 <Sukhdev> #topic: Action Items
16:07:40 <Sukhdev> manishg had an action item and he has posted a document on the Task Flow discussions
16:07:45 <Sukhdev> #link: https://docs.google.com/document/d/1aSgTVB7nW_v7lHH0Z0DUgfymEsx0O16k1Jgu7QFXkFA/edit#heading=h.fjb8xrfig499
16:08:02 <Sukhdev> I have not had chance to review it yet
16:08:15 <Sukhdev> Did anybody have a chance to review it?
16:08:38 <shivharis> I have not read it yet. Plan to do it today.
16:09:00 <Sukhdev> manishg: Want to give any heads up on this?
16:09:01 <manishg> Sukhdev: I didn't get a chance to look into midonet plugin (was my AI).  will do it this week.
16:09:03 <rkukura> I have not read it yet.
16:09:46 <manishg> Sukhdev: I think this is the discussion we've had here and so good to take it further from there.
16:09:51 <Sukhdev> Considering no body has read it yet, lets plan on using comment feature of google doc to post our comments on the doc itself
16:10:03 <rkukura> Sukhdev: +1
16:10:21 <manishg> Sukhdev: +1 (sorry, should have posted it yesterday and sent to ML)
16:10:31 <Sukhdev> manishg: Thanks a ton for putting this together
16:11:20 <Sukhdev> manishg: per last week's discussion, midonet plugin might give more insight to the implementation
16:11:20 <manishg> Please provide comments and I can add more documentation, etc.  I have not described taskflow related details as the taskflow docs are pretty detailed (and really impressive actually)
16:11:55 <manishg> yep, plan to look into it as soon as I can.
16:11:56 <Sukhdev> manishg: so, I would be very tempted to hear your findings on that front - please update the document accordingly
16:12:04 <manishg> I'll incorporate the learnings into the doc.
16:12:33 <Sukhdev> Anything on this document?
16:12:43 * Sukhdev waiting
16:13:21 <Sukhdev> #topic: Ironic integration through ML2 mech drivers
16:13:32 <Sukhdev> I added this topic for discussion
16:14:04 <Sukhdev> There is tremendous interest in this by many vendors - and, also Ironic team
16:14:33 <Sukhdev> The idea is to provide the same framework for BM which is avaialble for VMs
16:14:36 <shivharis> whats the idea behind this?
16:15:14 <Sukhdev> shivharis: make BM and VM launching as similar as possible
16:15:24 <Sukhdev> Nova has done it as well
16:15:56 <Sukhdev> If you are familiar  - to launch a BM or launch a VM - one will use the same command - i.e. "nova boot"
16:16:15 <Sukhdev> Other than the flavor, all parameters to nova boot command are same
16:16:29 <Sukhdev> flavor simply states it is a baremetal
16:16:57 <rkukura> Sukhdev: So would a —nic param be used for each physical NIC?
16:17:14 <Sukhdev> rkukura: yes
16:17:56 <rkukura> Sukhdev: And therefore, is the integration needed for neutron+ML2 to configure the ToR switch connected to each physical NIC?
16:18:18 <Sukhdev> In ironic, in order to launch BMs, the Physical nodes and ports are registered with the Ironic
16:18:28 <Sukhdev> rkukura: Yes - that is correct
16:18:53 <yamahata> What's the state transition of port?
16:19:16 <shivharis> Also does the physical host send out tagged and untagged frames?
16:19:32 <Sukhdev> yamahata: it is handled through ironic driver
16:19:57 <Sukhdev> shivharis: both implementations are being considered -
16:20:15 <Sukhdev> shivharis: BM servers go through two boot cycles -
16:20:37 <Sukhdev> First boot PXE - to fetch the images, etc.
16:21:11 <Sukhdev> once sufficient info is available, then it goes through the second boot to plumb into the neutron network
16:21:54 <Sukhdev> most of the nova<->neutron plumbing works as-is.
16:21:54 <rkukura> Sukhdev: Are the flat and/or VLAN networks used with ironic already represented in neutron with the corresponding network types, or is this part of what needs to be done?
16:22:57 <Sukhdev> rkukura: It is my understanding that most of the first boot is on a flat network
16:23:07 <manishg> rkukura: flat works fine.
16:23:41 <Sukhdev> It is a desire to use VLAN for the second boot - to provide multi- tenant support
16:24:12 <Sukhdev> The good news is that I have spent some time understanding this whole framwork
16:24:44 <Sukhdev> since everything goes through nova - most of the nova-neutron interactions are in play as-is
16:25:08 <rkukura> I’d think things like triple-0 build on ironic would want to use separate VLANs for admin, storage, external, and tunnel fabric, right?
16:25:11 <Sukhdev> some of the critical information needed to provision TORs for BM provisioning is missing in the port context
16:25:26 <rkukura> Sukhdev: What’s missing?
16:26:00 <Sukhdev> rkukura: The physical connectivity information (topology)
16:26:22 <rkukura> Sukhdev: Wouldn’t that be MD-specific?
16:26:37 <Sukhdev> I played around with a bit
16:26:38 <yamahata> Do you mean which physical host is connected to which ToR, etc?
16:26:56 <rkukura> I guess the port’s host would somehow be mapped to the ToR switch port by the MD, right?
16:27:09 <Sukhdev> rkukura: correct - but,  ML2 plugin will have to provide the conduit to allow passing of this information
16:27:23 <Sukhdev> yamahata: yes
16:27:49 <rkukura> Does nova+ironic set the binding:host_id for the port to the name of the BM host?
16:28:20 <Sukhdev> rkukura: now that is where it gets bit tricky -
16:28:52 <Sukhdev> The host name of BM to nova is where ironic conductor runs
16:29:34 <Sukhdev> rkukura: it uses binding:host-id, but, binds to the host name where the ironic conductor is running
16:29:56 <rkukura> Sukhdev: that sounds like a bug
16:30:12 <Sukhdev> rkukura: from nova point of view conductor is equivalent to a hypervisor
16:31:00 <Sukhdev> rkukura: first I thought the same, but, once understood a bit more, it make sense
16:31:05 <rkukura> Sukhdev: I think it is nova’s responsibility to properly set this when ironic is being used
16:31:41 <Sukhdev> rkukura: correct - and, most of the work to support this is in nova/ironic
16:31:50 <rkukura> The binding:host_id attribute is the host where the port is being accessed, not they host where some arbitrary nova component runs
16:32:26 <Sukhdev> rkukura: from ML2 point of view, the passage is needed so that additional information can flow to ML2 drivers when BM is launched
16:33:07 <rkukura> Sukhdev: What is needed other than the correc binding:host_id value?
16:33:10 <rkukura> correct
16:34:13 <Sukhdev> rkukura: The physical connectivity information - i.e. in addition to the mac address (which is already there), the switch ID and interface information
16:34:36 <rkukura> Does ironic already know all of this?
16:34:55 <shivharis> switchID? really
16:34:57 <Sukhdev> rkukura: I hacked the nova/Ironic to pass this information - and hacked ML2 to pass it down via port context - and all seems to hold up well
16:35:00 <rkukura> Or do we need something like the “topology service” that was proposed a couple cycles ago?
16:35:24 <Sukhdev> rkukura: Yes - there is way in Ironic to store it
16:36:09 <rkukura> Sukhdev: If we really need to add additional attributes to the portbinding extension, or a new extension, fine, but I really want to make sure this is necessary and that the existing attributes (like host_id) cannot be used where appropriate.
16:36:47 <Sukhdev> rkukura: topology service will not work for BM servers - as these are powered off, and no connectivity information can be automated - until after the first boot
16:37:39 <Sukhdev> shivharis: something to represent where the BM server is connected to
16:37:49 <rkukura> Sukhdev: If neutron had a topology extension API, I’d think ironic could populate it using that API.
16:38:23 <shivharis> so we are really looking for passthru (opaque) connectivity parameters
16:38:33 <Sukhdev> rkukura: possibly - but, I have to think through a bit more
16:38:36 <rkukura> Sukhdev: This definitely soulds like a good topic to discuss at the summit.
16:38:37 <Sukhdev> shivharis: yes
16:39:10 <Sukhdev> rkukura: yes, I discussed with mestery and have added to the etherpad - see item 63 on the etherpad
16:39:20 <sadasu> Sukhdev: thanks for collecting all this information so far
16:39:27 <shivharis> rkukura: so (if i got this correctly) we need to have an opaque field in the port binding...(right Sukhdev?)
16:39:37 <rkukura> I’d like to minimize how much special casing is needed in ML2 iteself for this sort of thing, just like I’m working to cleanup for DVR.
16:39:54 <sadasu> seems logical that diff vendors would be interested in this
16:40:10 <rkukura> We already have pass-through fields in both directions: binding:profile in, and binding:vif_details out.
16:40:24 <Sukhdev> sadasu: I have been approached by at least 3 vendors who need it
16:40:33 <rkukura> Both of these are dicts for which keys can be defined as needed.
16:41:06 <shivharis> rkukura: then we need to leverage what is already there
16:41:28 <shivharis> binding:xxx ?
16:41:28 <Sukhdev> rkukura: you bring up a good point - I missed those dicts.
16:41:30 <rkukura> Maybe ironic can just set binding:profile to include the info needed by BM MDs
16:42:05 <Sukhdev> rkukura: I will go back and look to see if those can be used - if yes, we do not need anything in neutron - :-):-)
16:42:39 <rkukura> Sukhdev: The nice things is that ML2 already knows to unbind/rebind ports when binding:profile is changed.
16:43:13 <Sukhdev> rkukura: let me look into it a bit more
16:43:22 <rkukura> Sukhdev: +1
16:43:48 <shivharis> rkukura: strawman binding:xxxx (fill in the xxxx with something suitable)
16:43:55 <Sukhdev> Wanted to bring to team's attention that there is great interest in this - Nova has already done a lot to make BM/VM work in a similar fashion
16:44:38 <rkukura> shivharis: I’m hoping we can avoid adding a new binding:xxxx atttribute, and can instead define new keys to be used in the existing binding:profile dictionary
16:44:40 <Sukhdev> Has anybody on this team looked into this? Will be nice to hear their experience...
16:45:14 <shivharis> somethings may not fit naturally - we'll see as we progress
16:45:34 <Sukhdev> rkukura: if it is a dict, I love the idea of reusing it by defining key-value pairs
16:46:11 <banix> no need for a new binding:xxxx
16:46:14 <Sukhdev> I wanted to give a heads up - that this is coming
16:46:19 <banix> what rkukura said
16:46:32 <Sukhdev> banix: correct - what rkukura said should do the trick
16:47:11 <shivharis> i am worried about stuff like switch id
16:47:24 <Sukhdev> shivharis: what is the worry?
16:47:46 <Sukhdev> shivharis: it is a vendor specific
16:47:50 <shivharis> it is different (vendor specific)
16:48:09 <shivharis> exactly  - you chimed at the same time
16:48:40 <Sukhdev> shivharis: you can call it anything you like - shivharis's driveway :-):-)
16:48:58 <Sukhdev> shivharis: gotta keep the humor going :-):)
16:48:59 <shivharis> never mind - we can still stuff everything in the existing..(implementation detail)
16:49:27 <Sukhdev> shivharis: yes, this is a key-value pair - one can call it anything they like
16:49:50 <Sukhdev> shivharis: from ML2 point of view, it is a pass throug
16:50:04 <Sukhdev> Shall we move on?
16:50:17 * Sukhdev waiting
16:50:23 <rkukura> If we really want a vendor-independent way to describe physical topology, I think we should consider a topology service within neutron.
16:50:36 <rkukura> Sukhdev: Lets move on.
16:51:25 <Sukhdev> #topic: Mid-cycle sprint
16:51:36 <Sukhdev> We covered this last week -
16:52:03 <Sukhdev> I have discussed with mestery and added task flow on the mid-cycle agenda
16:52:19 <Sukhdev> See item 4 here - https://etherpad.openstack.org/p/neutron-liberty-mid-cycle
16:52:37 <Sukhdev> We will use manishg document as basis for this
16:52:57 <Sukhdev> Once we agree on the design etc, this sprint will be for implementation
16:53:20 <Sukhdev> We will need volunteers to participate in this
16:53:45 <rkukura> I’m hoping to be there, but may have a conflict
16:54:18 <Sukhdev> rkukura: well this is a heads up - resolve the conflicts :-):-)
16:54:49 <rkukura> Sukhdev: I’m realizing that!
16:55:03 <Sukhdev> rkukura: bribe still works in conflict resolution :-):-)
16:55:24 <Sukhdev> Anything else on this?
16:55:47 <Sukhdev> rkukura: BTW, it is understood - I was just playing around :-)
16:56:22 <Sukhdev> #topic: Bugs
16:56:29 <Sukhdev> shivharis: anything on this?
16:56:32 <shivharis> not much to report on bugs for the kilo release
16:56:41 <shivharis> ; anyone has questions on bugs
16:56:50 <Sukhdev> Kilo is almost out
16:56:51 <shivharis> other than that we are good so far
16:57:02 <Sukhdev> anybody wants to bring up any bug?
16:57:15 * Sukhdev waiting
16:57:25 <Sukhdev> #topic: Open Discussion
16:57:43 <Sukhdev> Is everybody going to summit?
16:57:47 <rkukura> I should be filing the bug and submitting a patch for the DVR PortContext issues in a day or two
16:57:50 <Sukhdev> manishg is not going to make it
16:57:59 <banix> planning to attend
16:58:06 <rkukura> I’ll be at the summit
16:58:11 <shivharis> yes
16:58:34 <yamahata> I'll be there
16:58:43 <Sukhdev> Cool - looks like it will be full house
16:58:44 <asadoughi> yes, i'll be there
16:59:01 <Sukhdev> Anything on anybody's mind?
16:59:27 <Sukhdev> rkukura: Thanks for heads up on the bug and patch - will look for it
16:59:28 <banix> Sukhdev lots of things but I bet you don’t want to know
16:59:44 <sadasu> thanks for a productive meeting
16:59:44 <Sukhdev> banix: ha ha - same here :-):-)
16:59:56 <banix> :)
17:00:21 <rkukura> thanks Sukhdev!
17:00:30 <Sukhdev> Folks thanks for attending, and I agree with sadasu it was a productive meeting
17:00:30 <banix> thanks Sukhdev, all
17:00:33 <Sukhdev> bye
17:00:36 <banix> bye
17:00:38 <Sukhdev> #endmeeting