16:01:26 <Sukhdev> #startmeeting ironic_neutron
16:01:27 <openstack> Meeting started Mon May  9 16:01:26 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:31 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:41 <Sukhdev> #topic: Agenda
16:01:51 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_May_9.2C_2016
16:02:22 <Sukhdev> #topic: Announcements
16:03:04 <Sukhdev> Anybody has anything to announce?
16:03:18 <Sukhdev> This is first meeting after the summit
16:04:01 <Sukhdev> #topic: Recap of the discussions/agreements during the summit
16:04:13 <jroll> \o
16:04:34 <Sukhdev> I thought we spend few minutes to make sure are all on the same page as to what we discussed/concluded
16:04:48 <Sukhdev> not everybody was in every sessions
16:05:43 <Sukhdev> I had arranged a whiteboard session on Friday with critical cores from neutron to cover the two hot topics we had
16:06:22 <mlavalle> ++
16:06:31 <Sukhdev> devananda we looked for you, but, could not find you - but, sambetts mentioned that he in sync with you can could reasonably represent your position
16:07:29 <Sukhdev> on the first topic - Bonded/LAG support
16:08:00 <Sukhdev> our present implementation takes care of it and we felt nothing additional is needed from the neutron side
16:08:18 <Sukhdev> most of the work is in the ironic side
16:08:56 <Sukhdev> when a bonded port exists on ironic side, it maps to single port on neutron side
16:09:26 <Sukhdev> that is our current proposal anyways
16:09:35 <devananda> Sukhdev: on LAG support, I had thought that we (Ironic) needed a way to signal to neutron to create / destroy the bond. sambetts pointed out that, in theory, we already have that mechanism
16:09:58 <Sukhdev> devananda : yes
16:10:26 <Sukhdev> our current design supports that and our ML2 drivers supports it as well
16:11:22 <devananda> when attaching the Node to the provisioning network, Ironic should only attach the Port with the pxe_enabled flag
16:11:31 <Sukhdev> so, I think, we are good in this regard
16:11:41 <devananda> I have yet not checked if that is what the code actually does, though
16:12:10 * devananda looks
16:12:14 <devananda> yep - that's exactly what it does :)
16:12:19 <jroll> devananda: if you pass neutron a list of "switch info", the ML2 mechanism is supposed to configure the switch for bonding
16:12:21 <jroll> yeah
16:12:23 <devananda> so I think we're good on that side
16:12:43 <Sukhdev> cool
16:12:58 <Sukhdev> so, we are good with topic one -
16:13:31 <Sukhdev> lets get to the second topic (this one took a long time) - we walked through many cases to make sure we are covered
16:13:42 <Sukhdev> The trunked ports
16:14:41 <Sukhdev> so, neutron's trunk port spec, which is already merged and is in the middle of implementation mostly covers this support from neutron side
16:14:51 <Sukhdev> we need to make one change to that
16:15:54 <Sukhdev> when a sub port is added to the trunk port - it requires segmentation-id/type as a mandatory parameter - this forces some middle entity to change the tags
16:16:30 <Sukhdev> this works in ovs - but, in ironic case, we do not have that entity - i.e. the TOR will have to do it
16:17:15 <Sukhdev> sambetts raised the issue that we have to design for the lowest common denominator - i.e. there may be TORs which can not do the translation
16:17:33 <sambetts> o/
16:18:03 <Sukhdev> hence, everybody agreed that if modified the neutron API not to mandate the segmentation-id/type
16:18:14 <Sukhdev> sambetts : feel free to jump in
16:18:24 <Sukhdev> so, what this means is
16:19:25 <Sukhdev> if a user has a deployment with TORs which can do the translations, and they want to trunk various segmentation types (e.g. VLAN and VxLAN), they can do that
16:20:26 <Sukhdev> if the user has a plain vanila TOR that does not translate, they can still use trunk ports, in this case the segmentation-id of the network to which the sub-port is attached will be used
16:21:19 <sambetts> and if they have set a different sub-port segmentation type then binding will fail
16:21:20 <Sukhdev> I got the approval from three cores and PTL for this change -
16:21:44 <Sukhdev> sambetts : right, that would be considered mis-configuration
16:22:28 <Sukhdev> sambetts : has to modify his spec to match with this understanding
16:22:51 <sambetts> Yup :) I'll get that updating this week I hope
16:22:55 <sambetts> updated*
16:23:04 <Sukhdev> any questions on this?
16:24:06 <sambetts> My only question is still what to do about mapping a nova boot call with 2 ports to a node with 1 phys port, and if we should create a trunk port for the user
16:24:30 <sambetts> or if we just fail and tell them to go and make a trunk port manually themselves
16:25:15 <Sukhdev> sambetts : it actually depends -
16:25:47 <Sukhdev> if we say the deployment requires operators to create the trunk ports, then yes, the call fails -
16:26:21 <Sukhdev> but, if we say Ironic will create the trunk ports under the cover , the we accept the command
16:26:36 <sambetts> so make it configurable?
16:26:37 * jroll would prefer the latter
16:26:55 <jroll> I'd rather not have that configurable unless there's a very good reason
16:27:14 <Sukhdev> jroll +1
16:27:32 * sambetts would also prefer the latter
16:28:48 <Sukhdev> the question then comes to mind, do we have enough information to create the trunk port automatically?
16:29:26 <sambetts> I think so
16:29:44 <Sukhdev> then we are golden
16:30:52 <sambetts> the only part missing is the subport segmentation type/ID and if the network seg == VLAN, then leave sub port segmention blank, if network seg != VLAN then set subport segmentation to VLAN, and generate the seg ids
16:31:11 <sambetts> that covers that part as far as I can tell
16:32:05 <sambetts> this might also get us the ability to connect baremetal to non-VLAN segmentations for free
16:32:29 <sambetts> depending on your hardware/neutron configuration I guess
16:33:06 <Sukhdev> sambetts : with the modified neutron API, sub-port segmentation-id is optional - i.e. we do not need to specify, it will automatically map to network VLAN ID
16:33:26 <sambetts> when I say blank, I mean just don't include it, sorry :-P
16:33:41 <Sukhdev> got it - yes, that works
16:33:45 <sambetts> :D sweet
16:33:58 <sambetts> I'll try to update it all this week
16:34:27 <Sukhdev> Is everybody OK with this?
16:34:42 <Sukhdev> I did not see any rotten tomatoes flying by :-)
16:35:42 <Sukhdev> everybody in the room felt this was a good solution as well
16:36:19 <sambetts> awesome :)
16:36:33 <Sukhdev> once sambetts updates the spec, lets review it and make sure we are good to go with this
16:37:24 <Sukhdev> If nothing else on this topic, lets march forward to the next agenda item
16:37:44 <Sukhdev> #topic: Critical patches for early merge
16:37:46 <mlavalle> Sukhdev: do you have the url for that spec?
16:38:05 <Sukhdev> mlavalle : for sambetts's spec?
16:38:10 <sambetts> mlavalle: https://review.openstack.org/#/c/277853/
16:38:12 <mjturek1> +1, would like to read it
16:38:14 <mjturek1> thanks
16:38:23 <mlavalle> sambetts: thanks!
16:38:53 <Sukhdev> mlavalle : welcome to this part of the world
16:39:13 <mlavalle> Sukhdev: I just follow. I know that is where the fun is :-)
16:39:19 <mlavalle> follow you^^^
16:39:32 <Sukhdev> :-)
16:39:44 <Sukhdev> So, going back to the critical 4 patches
16:40:14 <Sukhdev> we had agreed to get 4 patches listed in the agenda to merge early
16:40:50 <sambetts> jroll: we're holding back until grenade is working right?
16:40:54 * sambetts runs and hides
16:41:11 <Sukhdev> sambetts : you can run, but, not hide
16:41:40 <sambetts> haha
16:42:11 <jroll> sambetts: yes, I'd rather not land this without upgrade testing
16:42:27 <jroll> sambetts: I'm not 100% against landing it, maybe 90%
16:42:36 <jroll> but that was what we talked about, yes
16:44:01 <devananda> FWIW, my test cluster hit a snag (unrelated) last week. Getting that running again so I can test the network integration on a couple racks is still on my priority list
16:44:06 <Sukhdev> many customers are ready to test this feature - managing too many patches is kinda hard
16:45:09 <devananda> Sukhdev: isn't there already an experimental CI job that tests this?
16:45:23 <devananda> yes - https://review.openstack.org/269157
16:45:31 <devananda> doesn't look up to date, though
16:46:25 <jroll> yeah, looks like it needs a rebase
16:47:13 <Sukhdev> jroll : so, can we come up a plan which will help us get these critical patches merged?
16:48:32 <devananda> sukhdev: for one, that patch chain should get updated / rebased. it's about a month stale at this point, and failed the last test runs
16:48:38 <jroll> Sukhdev: I've asked people to review them, they seem to be kind of on-and-off on it
16:48:46 <jroll> things that might get them more confident in the changes
16:48:54 <jroll> 1) upgrade testing running against it
16:49:02 <devananda> I also agree with jroll on our need for a grenade job (upgrade testing) because this is making some major changes to networks
16:49:03 <jroll> 2) smaller, incremental changes
16:49:19 <jroll> 3) updating the patches to pass CI, like deva mentioned
16:49:22 <devananda> in my testing, I already found out that the patches immediately broke my environment when applied
16:49:35 <devananda> because of a change to CONF defaults
16:49:47 <jroll> yay!
16:49:51 <devananda> yea...
16:49:57 <sambetts> I've left a comment in the network drivers migration covering one of those issues
16:50:58 <Sukhdev> hmm.. I see
16:51:32 <Sukhdev> time to chase some folks then
16:52:24 <Sukhdev> jroll : can you elaborate on 2) on your list - do you want these patches to be further broken down?
16:53:06 <sambetts> I'm also very interested in how the dhcp_provider thing should be handled, because IMO there are some problems if we can set network driver per node but the dhcp_provider is a global thing, if I have 1 node with a None network driver and 1 with a neutron network driver, and set dhcp_provider to Neutron, then it'll likely blow up in PXEBoot prepare ramdisk for the None node when it tries to
16:53:12 <sambetts> configure a neutron port for dhcp and there isn't one
16:53:25 <jroll> Sukhdev: it's always easier to review a smaller patch. you'll get more core reviewers with many small patches, rather than one large patch
16:53:55 <devananda> some of the patches are very hard to review -- eg, https://review.openstack.org/285852 is ~2000 lines
16:54:11 <devananda> sambetts: good question :(
16:55:06 * sambetts also thinks that there are some patches in that chain that can be broken out of the chain, like the devstack hwinfo one, because its cool to have regardless of the networking patches
16:56:52 <Sukhdev> sambetts and I spoke about the dhcp options issue on Friday during summit
16:57:29 <Sukhdev> sambetts : can you send me the links to the work that you had mentioned
16:57:59 <sambetts> can you remind me what I mentioned :/
16:58:10 <jroll> heh
16:58:31 <Sukhdev> sambetts : ha ha :-) lets take off line after this meeting - we are down to 2 min
16:58:51 <sambetts> Sukhdev: thanks my Brain is still decompressing from the summit
16:59:08 <Sukhdev> hshiina : are you here ?
16:59:12 <hshiina> yes
16:59:28 <Sukhdev> hshiina : you had added a topic to the agenda - we could not get to it
16:59:40 <hshiina> no problem
16:59:52 <Sukhdev> we are out of time - do you mind if we bring this up in next meeting?
16:59:55 <hshiina> ironic patches should be merged before nova's
17:00:07 <hshiina> i see
17:00:29 <Sukhdev> Folks, we are out of time -
17:00:39 <Sukhdev> thanks for attending
17:00:42 <sambetts> o/
17:00:46 <mjturek1> thanks!
17:00:53 <hshiina> thanks
17:00:55 <mlavalle> o/
17:01:07 <Sukhdev> bye
17:01:12 <Sukhdev> #endmeeting