14:03:57 <carl_baldwin> #startmeeting neutron_routed_networks
14:03:58 <openstack> Meeting started Tue Jul 12 14:03:57 2016 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:02 <openstack> The meeting name has been set to 'neutron_routed_networks'
14:04:06 <haleyb> hi
14:04:19 <carl_baldwin> #topic Agenda
14:04:29 <carl_baldwin> #link https://etherpad.openstack.org/p/routed-provider-networks-notes
14:04:38 <carl_baldwin> #topic Announcements
14:04:46 <carl_baldwin> Newton-2 is upon us.
14:05:25 <carl_baldwin> #link http://releases.openstack.org/newton/schedule.html
14:05:30 <carl_baldwin> I suspect it will be any time now.
14:06:00 <carl_baldwin> Any other announcements?
14:06:26 <mlavalle> arcelona Summit talks submission deadline is tomorrow
14:06:32 <mlavalle> Barcelona^^^^
14:06:56 <carl_baldwin> Thank you, mlavalle!  I had forgotten about that.
14:07:54 <carl_baldwin> Yesterday, I was able to boot a number of VMs on my routed network vagrant in various segments and talk between them all.  It was pretty cool.  I only had three un-merged patches cherry-picked: two for DHCP and one for Nova.
14:08:16 <john-davidge> nice!
14:08:23 <carl_baldwin> I was pretty excited so that's worth an announcement!
14:08:52 <carl_baldwin> Anyway, moving on...
14:08:59 <mlavalle> carl_baldwin: could you share in the etherpad the way to set up those patchsets?
14:09:14 <carl_baldwin> mlavalle: Sure, I can do that.
14:09:45 <mlavalle> Bin Yu is starting to write a scenario tempest test and we need that :-)
14:09:47 <mlavalle> Thanks
14:10:14 <carl_baldwin> Great.
14:10:23 <carl_baldwin> This is looking pretty impressive:
14:10:24 <carl_baldwin> #link https://review.openstack.org/#/q/-status:abandoned+topic:bp/routed-networks
14:11:03 <carl_baldwin> Cores, haleyb, kevinbenton, blogan:  Try to keep an eye out for patches that just need one more +2.  We've got a few.
14:11:23 <blogan> carl_baldwin: will do
14:11:31 <haleyb> ack
14:11:50 <carl_baldwin> Also, make sure your patches have the right topic so that they appear on this page.
14:13:27 <carl_baldwin> #topic deferred IP allocation
14:14:12 <carl_baldwin> I think we've made good progress here.  I see some comments from johnthetubaguy on my patch
14:14:14 <carl_baldwin> #link https://review.openstack.org/#/c/299591/
14:14:24 <carl_baldwin> Thanks, johnthetubaguy for your continued attention to this.
14:14:58 * neiljerram is sorry to be late
14:15:07 <carl_baldwin> We don't have the most efficient solution yet but it was very cool to see nova VMs boot on segments and even retry to another host when the segment is out of IPs.
14:15:57 <carl_baldwin> I think what we'll have to do is have early adopters monitor IP usage across the segments to make sure there are IPs available.
14:16:17 <mlavalle> Correct
14:16:59 <carl_baldwin> Also, I need to follow up in Neutron by fleshing out the new ip_allocation extension that was merged.
14:17:23 <carl_baldwin> #action carl_baldwin will follow up on ip_allocation extension.
14:18:01 <carl_baldwin> #topic DHCP
14:18:04 <carl_baldwin> blogan: hi
14:18:11 <blogan> carl_baldwin: hi
14:18:28 <blogan> carl_baldwin: so i put up a patch to fix the create and update of dhcp port
14:18:32 <carl_baldwin> blogan: I did run with your patch yesterday and it did fix some things.
14:18:50 <carl_baldwin> blogan: I had to leave my review but I'll pick it up again today.
14:19:39 <blogan> carl_baldwin: i think we can fix both of these issues by making the get_network_info rpc callback method only return subnets for segment that host is mapped to, if segments exist for that network
14:20:22 <carl_baldwin> That is an interesting thought.
14:20:36 <blogan> i was attempting to test it out last night, but vagrant wasn't complying so i went to bed in protest
14:21:22 <carl_baldwin> blogan: That happens
14:21:26 <mlavalle> blogan: that is a good way to protest
14:21:28 <carl_baldwin> blogan: So that would fix this too:
14:21:37 <carl_baldwin> #link https://review.openstack.org/#/c/340592
14:21:54 <blogan> yeah, i think it would
14:22:33 <carl_baldwin> Cool.  That would get us in a good place.
14:22:34 <blogan> ill be able to test it out today though and give a good answer
14:23:15 <carl_baldwin> You you think that should have an RPC API change?
14:24:16 <blogan> no, the rpc callback method would decide whether the segments are enabled and if the network has segments, then it'll filter for only those segments the host is mapped to
14:24:37 <carl_baldwin> blogan: Sounds straight-forward.
14:24:56 <carl_baldwin> Is there anything else wrt DHCP that should be brought up?
14:25:28 <asingh> i was working on auto scheduling for segments
14:25:41 <asingh> https://review.openstack.org/#/c/333716/
14:25:54 <blogan> yeah i need to get that reviewed too :)
14:26:02 <blogan> thanks for bringing that one up asingh
14:27:03 <asingh> thanks blogan
14:27:32 <carl_baldwin> asingh: I'll have a look.
14:27:51 <carl_baldwin> #topic Integration with Nova Scheduler
14:27:52 <carl_baldwin> mlavalle:
14:27:56 <mlavalle> hi
14:28:21 <mlavalle> Over the past few days I deployed the generic resource pools in my vagrant environment
14:28:40 <mlavalle> The api is mostly working as expected
14:28:55 <carl_baldwin> cool
14:28:59 <mlavalle> I discovered a few issues that I communicated to Chris Dent, the developer
14:29:27 <mlavalle> So I will continue helping him by testing what he pushed to Gerrit
14:29:54 <mlavalle> I am also going to start writing today a python client for that API
14:30:20 <mlavalle> Chris was supposed to do that, but he hasn't had the time to do it
14:30:37 <carl_baldwin> mlavalle: I'm sure he will appreciate that very much.
14:30:41 <mlavalle> And we need the client to write our piece in Neutron that talks to that API
14:31:04 <mlavalle> Yes, this is agreement with him
14:31:28 <carl_baldwin> Sounds like great progress.
14:31:36 <mlavalle> My goal is to write our the Neutron interaction with grp as soon as possible
14:31:44 <mlavalle> That way we will have time to mature it
14:32:18 <carl_baldwin> grp = generic resource pools right?
14:32:39 <mlavalle> Yes, sorry, I am assuming people unsderstand that
14:33:09 <mlavalle> I will keep an eye on you nova patch for deferred ip
14:33:12 <carl_baldwin> Just trying to help out the uninitiated
14:33:38 <carl_baldwin> mlavalle: This sounds like great progress.  Keep pushing forward.
14:33:42 <mlavalle> Based on how that evolves I will continue the changes I am making to allocate_for_instance
14:34:04 <mlavalle> Finally, I will roll out a patchset this week to show segments in ports
14:34:23 * carl_baldwin wonders how many mlavalle s are out there
14:34:37 <mlavalle> That's it, Thanks!
14:34:50 <carl_baldwin> mlavalle: Do you need any assistance with any of these?
14:35:04 <mlavalle> Not now, but I will yell if I do
14:35:05 <carl_baldwin> mlavalle: Please ping me any time you need reviews or anything.
14:35:37 <carl_baldwin> mlavalle: Is that it?
14:35:51 <mlavalle> that's it. Thanks!
14:36:02 <carl_baldwin> Oh, you already said that.
14:36:05 <carl_baldwin> thanks
14:36:06 <mlavalle> LOL
14:36:09 <carl_baldwin> #topic L2 Adjacency Extension
14:36:22 <carl_baldwin> reedip: neiljerram: hi
14:36:31 <carl_baldwin> neiljerram: I saw your comments on the patch set.
14:36:34 <neiljerram> carl_baldwin, hi
14:36:47 <carl_baldwin> Did you see my reply?
14:36:50 <neiljerram> carl_baldwin, thanks; I saw your response too
14:37:20 <carl_baldwin> neiljerram: Calico is ML2, right?
14:37:59 <neiljerram> networking-calico can currently be a core plugin or an ML2 driver - but the clear steer from Neutron as a whole is for it to focus on being ML2, I believe.
14:38:47 <carl_baldwin> neiljerram: That might explain my confusion.  I wasn't aware of the duality.
14:39:07 <neiljerram> (I'd like to keep networking-calico in the Neutron stadium, and I believe that being ML2 is more-or-less a requirement for that, as it encourages us all to align our implementation approaches)
14:39:17 <carl_baldwin> When I made my original comments, I was thinking of it as a core plugin.  I thought it could just implement the extension on its own.
14:39:22 <neiljerram> Understood.
14:40:28 <carl_baldwin> I'm thinking we might need our implementation to call the core plugin and pass the network.  Then, in ML2, the mechanism driver could answer for the particular network.  Does that sound about right?
14:40:29 <neiljerram> Well how about if the current review proceeds on the assumption that an ML2 driver cannot control l2-adjacency, and then I take on whatever work is needed so that a driver can influence that?
14:41:24 <carl_baldwin> neiljerram: That sounds fine.
14:41:31 <neiljerram> The only think is, I'm not sure it's correct (in all scenarios) that a Network is 'owned' by one mechanism driver.
14:42:23 <neiljerram> Remembering rkukura's talk in Austin, I think there are scenarios where multiple ML2 drivers cooperate to do setup for a Network - e.g. at different levels.
14:42:24 <carl_baldwin> neiljerram: Yes, the driver "owns" the segment, right?
14:43:21 <neiljerram> I'm not sure, I'm afraid (in general).
14:43:52 <mlavalle> That is for Hierarchichal Port Binding
14:44:07 <neiljerram> mlavalle, right.
14:44:21 <carl_baldwin> I'm thinking the segments service plugin could have the first chance to answer "not adjacent".  Then, maybe the mechanism drivers could have a chance to answer "not adjacent" too.
14:44:56 <neiljerram> That sounds like it could make sense.
14:45:35 <neiljerram> If one thinks of what mechanism drivers actually do, those things would influence whether or not there was real l2 adjacency.
14:45:54 <carl_baldwin> neiljerram: I agree.
14:45:56 <neiljerram> And if any of them says "not", that breaks the chain.
14:46:25 <carl_baldwin> neiljerram: I also think this could be done in two stages as you suggest.  Let's work together to get these lined up.
14:46:53 <neiljerram> OK, will do.  I will put up a separate patch that builds on reedip's.
14:46:55 <carl_baldwin> neiljerram: I'll try to get the patch that's up in to shape for the segments service plugin piece.
14:47:13 <carl_baldwin> #action carl_baldwin will get l2 adjacency patch in to shape.
14:47:50 <carl_baldwin> neiljerram: Sounds like a plan.
14:49:25 <carl_baldwin> #topic Open Discussion
14:49:46 <carl_baldwin> Let's catch anything else you've brought to discuss now.
14:50:34 <john-davidge> I've posted an update to the first subnet service types patch this morning #link https://review.openstack.org/#/c/337851
14:51:04 <john-davidge> Currently aving some trouble with DB/model sync issues that i didnt catch locally but its now in a state where unit tests are passing
14:51:17 <john-davidge> still very much WIP but thought it was worth getting it out there
14:51:58 <carl_baldwin> john-davidge: Great, I'll have a look.
14:52:09 <haleyb> john-davidge: thanks for the update.  I saw a comment about having to add to the subnet model?
14:52:34 <john-davidge> carl_baldwin: thanks
14:53:07 <john-davidge> haleyb: Yes, I couldn't see a way to avoid that myself, I commented on the patch. If you or Carl have any ideas im all ears
14:54:40 <carl_baldwin> I'll have to give my half-baked idea there some more thought.
14:54:53 <haleyb> john-davidge: ok, i'll comment in the patch
14:55:20 <john-davidge> carl_baldwin: haleyb: Thanks guys
14:57:33 <carl_baldwin> If I get a little time, I might start trying to set a router external gateway to a routed network.  See what comes up.
14:58:11 <john-davidge> carl_baldwin: Cool, would be interested to see the results
14:58:41 <carl_baldwin> Well, we're about out of time.  Thanks for everything!
14:58:49 <carl_baldwin> #endmeeting