15:00:27 <carl_baldwin> #startmeeting neutron_routed_networks
15:00:29 <openstack> Meeting started Tue Mar 29 15:00:27 2016 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:33 <openstack> The meeting name has been set to 'neutron_routed_networks'
15:00:44 <carl_baldwin> #topic Announcements
15:00:52 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Routed-Networks
15:01:20 <carl_baldwin> We had one patch merge!
15:01:26 <mlavalle> yaay
15:01:59 <carl_baldwin> It was the patch by gongysh and mlavalle to move the networksegments table to make it available to all plugins.
15:02:23 <carl_baldwin> Thank you mlavalle for jumping in and taking care of the migration aspects of that change.  I know that wasn't trivial.
15:02:31 <mlavalle> :-)
15:02:43 <mlavalle> I learned a few things
15:02:58 <mlavalle> so thank you
15:03:08 <carl_baldwin> I'm hoping we can get a steady pace of merging small but meaningful changes like this.
15:03:36 <carl_baldwin> #link https://review.openstack.org/#/c/296603/
15:04:13 <carl_baldwin> ^ Next up to merge.  I think it is good to go.  It passed tests but I noticed a merge conflict was going to hit it and rebased preemptively.
15:04:15 <reedip__> hi
15:05:06 * carl_baldwin truly thinks small meaningful patches is the best way to get things merged.
15:05:15 <carl_baldwin> Any other announcements?
15:06:09 <carl_baldwin> Okay, let's move on to discuss progress.
15:06:56 <carl_baldwin> I already hit the first two points, the next one is...
15:07:01 <carl_baldwin> #topic IPAM
15:07:29 <carl_baldwin> I started working on some IPAM aspects yesterday and I think I might have a plan forward.
15:07:55 <neiljerram> Interesting!
15:08:28 <carl_baldwin> Basically, the thought is to introduce groups to IPAM.  When we create a subnet, we'll pass in a group_id to IPAM to record with the subnet.
15:09:08 <carl_baldwin> Of course, we'll have to have a way to ask the plugin if it supports the feature because we'll require it for segments support.
15:09:22 <neiljerram> What does the group_id represent?
15:10:24 <carl_baldwin> neiljerram: a group!
15:10:27 * carl_baldwin kidding
15:10:33 <neiljerram> :-)
15:11:13 <carl_baldwin> neiljerram: I was thinking a group of subnets within the network.  I'm not sure yet if it needs to be more than that.
15:12:12 <carl_baldwin> When we want an IP allocation from the network, we pass in the group id (or None).  IPAM will select subnets matching the group for allocation.
15:12:58 <carl_baldwin> I was thinking we could also somehow configure it for hard or soft boundaries (does IPAM go outside the group if there are no more IPs left in the group).
15:13:41 <carl_baldwin> I hope to have some code up soon to illustrate how it will work.
15:13:45 <neiljerram> Sounds interesting, although I'm afraid I'm not yet seeing the idea fully....
15:14:23 <neiljerram> Out of interest, are you thinking of adding this into the existing spec, or of finishing that one up and starting a separate one?
15:14:48 <neiljerram> I'd say probably better to bank the existing one first.
15:14:54 <carl_baldwin> neiljerram: I was thinking of doing this under the current spec.
15:15:16 <neiljerram> I'm sure that would be fine too!
15:16:32 <carl_baldwin> neiljerram: Your desire, if I understand, is to group cidrs by host for route aggregation, right?  You could map hosts to a group.  My desire is to group them by segment.
15:16:58 <neiljerram> carl_baldwin, Correct.  So in general the idea of generalizing that grouping sounds good.
15:17:33 <carl_baldwin> neiljerram: It isn't a fully baked idea yet.  But, I wanted to bring it up for discussion.  I'll take it to the ML today.
15:18:16 <egon> Do you have an etherpad, or something for fleshing out ideas?
15:18:23 <carl_baldwin> It might even be possible to work in what haleyb is working on with service subnets.  I'll have to think about that.
15:18:41 <carl_baldwin> egon: Not for this one at the moment.
15:19:06 <carl_baldwin> egon: That might be the way to go.  Watch the ML for the moment.
15:19:31 <egon> There's a few use cases that might benefit from being able to be "guided" into a CIDR block, or tenants/users restricted from using one.
15:19:55 <egon> It does matter as much until you get BYO CIDR...
15:20:01 <egon> er.. does not.
15:20:47 <carl_baldwin> #action carl_baldwin will post to the ML about IPAM subnet groups (or whatever we decide to call them).
15:20:59 <carl_baldwin> Anything else for right now on this subject?
15:21:02 <neiljerram> Am I right in thinking that Neutron already allows a Network to have multiple Subnets?  If so, then there are already IPAM things that I don't understand - which subnet is used.
15:21:39 <neiljerram> But don't need to cover that now - sorry!
15:22:00 <carl_baldwin> neiljerram: Yes, it does.  Let's take it to the ML.  That is a good point.  It is important to understand how IPAM handles that.
15:22:03 <reedip__> neiljerram: a network can have multiple subnets in neutron
15:22:15 <carl_baldwin> #topic Nova Scheduler
15:22:33 <carl_baldwin> mlavalle: hi again.
15:22:37 <mlavalle> hi
15:23:10 <mlavalle> so I have been attending the Nova scheduler meetings to make sure we keep the Nova attention team on our spec
15:23:29 <carl_baldwin> jaypipes pinged me this morning to have a discussion about this over Hangouts.
15:23:38 <carl_baldwin> #link https://review.openstack.org/263898
15:24:00 <mlavalle> We have agreed that the routed networks spec for Nova will be discussed weekly during that meeting
15:24:18 <carl_baldwin> He's going to ping me at 3pm MDT.
15:24:31 <mlavalle> yeah, he pinged me at the same time
15:24:40 <mlavalle> so I will join the conversation
15:24:55 <carl_baldwin> Have you all seen this diagram?
15:24:57 <carl_baldwin> #link https://drive.google.com/file/d/0B4AotMGstEW6TE5XdzMxWXhHa3M/view?usp=sharing
15:25:32 <neiljerram> I have now - great diagram.
15:25:46 <carl_baldwin> It is sort of a state diagram showing the three paths from no port to a VM with an IP.
15:26:04 <carl_baldwin> neiljerram: Thanks, it was getting too difficult for me to keep thinking about it in my head.
15:26:16 <carl_baldwin> ... and remember some of the more subtle transitions.
15:26:20 <neiljerram> IIUC from the spec, there is at least one common scenario where it's already true that Neutron does its IP allocation _after_ Nova has chosen the compute host.
15:26:28 <mlavalle> as background for the team, we see 3 use cases from the nova perspective: nova creates the port, nova receives a port with no ip address and nova recived a port with ip address
15:26:49 <carl_baldwin> mlavalle: exactly, thanks.
15:27:16 <neiljerram> Which one happens if you use Horizon and just specify the network to attach to?
15:27:18 <mlavalle> for the first 2, we think we have specified the mechanism needed to handle them
15:27:27 <carl_baldwin> We haven't made as much progress on this as I'd hoped in the last week.  I was hoping for at least two more comments like mlavalle 's on the spec.
15:27:41 <carl_baldwin> Thank you mlavalle for spelling out your proposal on the spec.
15:27:42 <mlavalle> the difficult one is the third one
15:27:42 <neiljerram> I'm sorry - I did read, but didn't comment.
15:28:06 <mlavalle> last night I came up with a rough idea of another approach
15:28:23 <mlavalle> I call it "eventually nova consistent" approach
15:28:57 <mlavalle> in this approach we let nova's view to become outdated for brief periods of time
15:29:12 <mlavalle> I will add it as comment to the spec later today
15:29:27 <mlavalle> the idea came to me last night after yoga class
15:29:53 <mlavalle> my intent is to minimize the synchronization needed between nova and neutron
15:30:02 <carl_baldwin> mlavalle: I'll call it the "yoga solution".  ;)
15:30:55 <mlavalle> the conversation with jaypipes later today will be useful to flesh out this idea
15:30:55 <carl_baldwin> mlavalle: Another approach I'm thinking about is talked about in the state diagram above (#2 at the top).  I'll give that some more thought too.
15:31:21 <neiljerram> ( carl_baldwin - about that diagram, actually it's rather small to read easily, and goes fuzzy when I try to enlarge it... )
15:31:50 <carl_baldwin> neiljerram: You need to "open" it in your browser.
15:32:02 <neiljerram> carl_baldwin, I did, I think..
15:32:14 <mlavalle> neiljerram: going back to your comment, the use case that happens in horizon is nova creates the port
15:32:16 <reedip__> How to open int in the browser?
15:32:51 <neiljerram> mlavalle, thanks.  I'll re-read the spec and comment this time!
15:32:57 <carl_baldwin> neiljerram: After clicking the link, at the top there is an "open with" which creates yet another tab in your browser.
15:33:07 <carl_baldwin> reedip__: ^
15:33:44 <carl_baldwin> Make sense?
15:33:52 <mlavalle> carl_baldwin: one thing I think we also need to clarify today with Jay is how resources are released in resource pools
15:33:56 <reedip__> got it opened
15:34:03 <reedip__> thanks carl_baldwin
15:34:17 <mlavalle> carl_baldwin: I haven't seen that spelled out in any of the specs
15:34:27 <carl_baldwin> mlavalle: ++
15:34:48 <carl_baldwin> Anything more we can / should discuss on this now?  We've got a couple of other things.
15:35:09 <carl_baldwin> Okay, moving on
15:35:16 <carl_baldwin> #topic Host / Segment mapping
15:35:23 <mlavalle> hi again
15:35:28 <neiljerram> carl_baldwin, that only gives me web-based options, including draw.io which asked for access to my google drive...  All I want is a decent resolution .png or .svg download...
15:35:45 <mlavalle> I saw your comment to the patchset yesterday
15:35:53 <carl_baldwin> The thing that came up here is if we should continue with the assumption that we are only going to map hosts to physical networks or if we should do true host / segment mapping.
15:36:03 <mlavalle> #url https://review.openstack.org/#/c/285548/
15:36:29 <mlavalle> so I spent a chunk of the afternoon going through the other patchset
15:36:47 <mlavalle> #url https://review.openstack.org/#/c/205631
15:36:56 <mlavalle> yes, it useful
15:37:02 <mlavalle> it is useful
15:37:05 <carl_baldwin> neiljerram: I'll post something else.
15:37:13 <neiljerram> carl_baldwin, thanks!
15:38:35 <neiljerram> So, is that assumption ML2-specific, or implementation-related?
15:38:46 <mlavalle> carl_baldwin: could you explain further the difference between phys net mapping and segment mapping?
15:38:49 <neiljerram> Or is it something represented in the API / data model?
15:38:55 <carl_baldwin> neiljerram: No, it isn't ML2 only.
15:39:26 <carl_baldwin> neiljerram: It is a data model now and could be reflected in plugin API.
15:39:58 <carl_baldwin> mlavalle: A segment is more than a physical network.  It adds segmentation id and type.
15:40:30 <mlavalle> carl_baldwin: correct. But a segment maps to a physnet, correct?
15:40:49 <mlavalle> and it has its added attributes
15:40:58 <carl_baldwin> mlavalle: That is the thing we're thing to determine.
15:41:19 <mlavalle> carl_baldwin: I was looking here: https://review.openstack.org/#/c/205631/33/neutron/tests/unit/plugins/ml2/test_plugin.py
15:41:31 <carl_baldwin> I guess my question is are there valid reasons to need multiple segments within a physical network.
15:41:54 <neiljerram> It seems to me that segment is the established concept in Neutron, so I'd be inclined to map to that.
15:42:15 <mlavalle> carl_baldwin: I am not clear on that. However, the code I see in the patchset I just mentioned suggests that segments and phys nets map 1 to 1
15:42:50 <neiljerram> Well, multiple VLANs on a single physical network...
15:44:11 <mlavalle> carl_baldwin: so I was thinking to ping Kevin Benton later today and have this conversation
15:44:30 <carl_baldwin> mlavalle: Should we take this to the ML?
15:44:49 <mlavalle> carl_baldwin: good idea. I'll send a message as soon as we finish this meeting
15:45:19 <carl_baldwin> mlavalle: Thanks.
15:45:54 <carl_baldwin> #action mlavalle will post to the ML about host mapping (are segments 1-1 with physical networks?)
15:46:25 <carl_baldwin> #topic Create / delete segment in ML2
15:46:45 <carl_baldwin> I briefly started looking at this but decided to put it on the back burner.
15:47:13 <carl_baldwin> Right now, I have a patch up that enables segments API in ML2 but only to view segments created through provider and multi-provider extensions.
15:47:24 <carl_baldwin> #link https://review.openstack.org/296658
15:47:54 <carl_baldwin> The reason is that it may not be trivial to enable create / delete on segments with an existing network.
15:48:06 <carl_baldwin> #link https://review.openstack.org/284440
15:48:32 <carl_baldwin> Separating this out let's me focus on the IPAM aspects we already discussed.
15:48:53 <carl_baldwin> Is anyone familiar enough with segments and ML2 who would like to try to progress this further?
15:50:05 <neiljerram> I've spent time trying to understand that - but probably not enough yet to really help.
15:50:50 <carl_baldwin> Ok, get the word out that this could use some attention.  It should ideally be someone already familiar with ML2.
15:51:11 <carl_baldwin> I'll leave it on the back burner while we make progress in other areas.
15:51:34 <carl_baldwin> However, it would be really restrictive to not be able to add segments to an existing network in the long run.
15:51:36 <carl_baldwin> :)
15:51:50 <mlavalle> indeed
15:52:20 <carl_baldwin> Also, making some progress on this in parallel with other efforts would be a big win!
15:52:31 <carl_baldwin> #topic Segment aware DHCP
15:52:53 <carl_baldwin> A related patch merged yesterday
15:53:00 <carl_baldwin> #link https://review.openstack.org/205631
15:53:08 <carl_baldwin> (already mentioned by mlavalle in this meeting)
15:53:33 <mlavalle> yeah, it sheds light on our efforts
15:54:28 <carl_baldwin> This is another area that is up for grabs.  In terms of difficulty it might be a little bit easier than the create / delete segments one.
15:54:50 <carl_baldwin> I have ZZelle in mind for this but I'm not sure of his availability.
15:55:17 <carl_baldwin> #action carl_baldwin will ping ZZelle (and maybe amuller) about helping us to make progress in this area.
15:55:46 <carl_baldwin> #topic Client
15:55:52 <carl_baldwin> Anyone here to discuss the client?
15:56:05 <mlavalle> rtheis: ^^^
15:56:16 <rtheis> here
15:56:26 <carl_baldwin> mlavalle: Thanks, I was just looking up the spelling of rtheis 's nic.
15:56:29 <reedip__> present
15:56:39 <carl_baldwin> reedip__: Hi
15:56:45 <mlavalle> yeah reedip__ is also helping here :-)
15:57:14 <rtheis> carl_baldwin: I have the OSC patches out as WIP
15:57:25 <carl_baldwin> rtheis: cool
15:57:39 <rtheis> I will update them with name and description support as soon as that works
15:57:57 <carl_baldwin> I hope to have another API change up for review adding segment_id to subnets.  That'll be the next thing to need client support.
15:57:59 <reedip__> I will follow up on my work of name and desc with the PROPER checkouts
15:58:29 <rtheis> ok
15:58:33 <reedip__> carl_baldwin: okay
15:58:33 <carl_baldwin> It'll be a new patch set on an existing review
15:58:34 <carl_baldwin> #link https://review.openstack.org/288774
15:59:00 <carl_baldwin> reedip__: Thanks.
15:59:18 * carl_baldwin notes time
15:59:31 <rtheis> carl_baldwin: One item that I'm pondering is where this OSC code should live...python-openstackclient or python-neutronclient (as OS plugin)
15:59:44 <rtheis> the network segment CLI that is
15:59:54 <rtheis> seems like this is core and should go in OSC
16:00:00 <rtheis> that's were I'm leaning
16:00:03 <carl_baldwin> rtheis: I think you're the resident expert for deciding that.
16:00:05 <carl_baldwin> ;)
16:00:14 <rtheis> :)
16:00:21 <carl_baldwin> Okay, we're out of time.
16:00:23 <reedip__> plugin wont make a strong sense here
16:00:23 <carl_baldwin> #endmeet
16:00:23 <rtheis> opinions welcome
16:00:28 <carl_baldwin> #endmeeting