15:04:00 <carl_baldwin> #startmeeting neutron_routed_networks
15:04:01 <jasondotstar> carl_baldwin: sorry, got hear 1hr early. your team has the floor.
15:04:03 <openstack> Meeting started Tue Mar  1 15:04:00 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:04:04 <vikram_> hi
15:04:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:07 <openstack> The meeting name has been set to 'neutron_routed_networks'
15:04:15 <carl_baldwin> jasondotstar: No worries, it happens.  I did it last week.  ;)
15:04:28 <carl_baldwin> #topic Announcements
15:04:45 <mlavalle> hi
15:05:04 <carl_baldwin> I think the latest version of the spec has general consensus.  At least, I haven't heard any arguments against it.
15:05:10 <carl_baldwin> And there is good support for it.
15:05:29 <carl_baldwin> I'll try to keep the agenda on the meetings page.
15:05:32 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Routed-Networks#March_1st.2C_2016
15:05:52 <carl_baldwin> minus the stuff after the #
15:06:25 <neiljerram> But I have at least a query...
15:06:45 <carl_baldwin> neiljerram: Please, present it.  :)
15:07:07 <neiljerram> It's a bit long for here - I commented early Monday.
15:07:40 <neiljerram> But in summary, it's about how Segment objects relate (or not) to segment descriptions in the multi-provider extension
15:07:40 <carl_baldwin> neiljerram: I will look for it.  I did not see it yesterday.  Though, yesterday was filled with other catching up.
15:08:18 <neiljerram> carl_baldwin, Thanks - and I'm sorry for not getting to a full re-review earlier than I did.
15:08:43 <carl_baldwin> neiljerram: They certainly relate.  They share a table.
15:09:35 <carl_baldwin> neiljerram: The segments of the multi-provider extension are being "promoted" to a first class thing.  Both extensions will be different views to the same data.
15:10:44 <neiljerram> So how can there be independent CRUD for Segment objects then?  Surely the only Segment objects that should exist are those implied by the content of the multi-provider (or provider) extension?
15:10:52 <carl_baldwin> I hope that one day we can consolidate the extensions.  The multi-provider extension has some usability drawbacks.
15:11:53 <carl_baldwin> neiljerram: It is a single data model with different views.
15:13:05 <carl_baldwin> The announcement that I had is that we are beginning to collect code contributions on the gerrit topic.
15:13:08 <carl_baldwin> #link https://review.openstack.org/#/q/status:open+topic:bp/routed-networks
15:13:34 <carl_baldwin> These are all WIP for now but will be fleshed out quickly.
15:13:49 <vikram_> nice
15:13:53 <carl_baldwin> I actually have another patch locally that I will put up soon.
15:14:42 <neiljerram> carl_baldwin, So, for example, if a Network was configured with multiprov seg1,seg2,seg3, three corresponding Segment objects would be auto-created.  And then if a fourth Segment object was added by the operator, it would be as though the Network had been reconfigured with seg1,seg2,seg3,seg4 ?
15:14:59 <carl_baldwin> And, I'm going to pull in an existing patch to move the segments table out of ML2 and in to core.  Let me find a link.
15:15:39 <carl_baldwin> neiljerram: That sounds about right.
15:17:11 <carl_baldwin> #link https://review.openstack.org/#/c/242393/
15:17:17 <neiljerram> carl_baldwin, OK thanks.  I'll defer to continuing this in Gerrit now, so as not to derail the meeting here.
15:17:18 <carl_baldwin> ^ Patch to move segments table.
15:17:58 <carl_baldwin> neiljerram: Do you see something fundamentally wrong with this approach?
15:18:23 <mlavalle> carl_baldwin: is this patchset going to be the head of the dependency chain?
15:18:37 <carl_baldwin> mlavalle: Yes, once I get things rebased.
15:18:49 <mlavalle> carl_baldwin: ++
15:18:57 <neiljerram> carl_baldwin, No; but I means that Calico can't use Segments to express its clustered IP allocation desires
15:19:05 <neiljerram> s/I means/it means.
15:20:37 <carl_baldwin> neiljerram: That is a good point.  My impression of our past conversations was that it wasn't going to work for that use case and you were looking at host aware IPAM.
15:21:32 <carl_baldwin> mlavalle: I had started that work on the plane and made some progress.  I need to button it up and get it posted.
15:22:23 <mlavalle> carl_baldwin: ok, i'll wait for you to post it and then align my patchset with it
15:22:52 <carl_baldwin> neiljerram: This is worth some more discussion.
15:23:18 <carl_baldwin> #topic Work items
15:23:23 <carl_baldwin> #link https://review.openstack.org/#/c/225384/18/specs/mitaka/routed-networks.rst
15:23:39 <neiljerram> carl_baldwin, Yes, more discussion.  (I guess you mean the difference between hard and soft boundaries.  But I think there are remaining migration questions for VMs in a genuinely segmented network too.)
15:24:06 * carl_baldwin realizes he has some draft comments in reply to feedback from armax still on the spec. Needs to wrap that up.
15:24:55 <carl_baldwin> I laid out work items starting on line 443
15:25:13 <carl_baldwin> I got started on the first one and have a WIP patch up for that.
15:25:50 <carl_baldwin> mlavalle: you have started, and made good progress, on the third.
15:26:10 <mlavalle> carl_baldwin: yeah
15:26:36 <carl_baldwin> By the end of the week, I'll have patches up for the rest of the sub-items in the first bullet.
15:27:01 <carl_baldwin> neiljerram: Not ignoring your comment.  Let's get to it in a few minutes.
15:28:02 <carl_baldwin> To be honest, I may need someone to help contribute to the segments model.  I get pulled away from it a lot and so progress is slow.
15:28:40 <carl_baldwin> We also have a need for someone to start playing around with deferred IP allocation.
15:28:58 <neiljerram> carl_baldwin, I am definitely interested in the latter.
15:29:08 <mlavalle> carl_baldwin: I am available to help...... you tell me where you want me to help
15:29:21 <mlavalle> carl_baldwin: besides what I am already doing
15:30:46 <carl_baldwin> neiljerram: Great.  Let me know what you need to get going on that.
15:31:20 <neiljerram> I could do with a good and exhaustive picture of what the Nova/Neutron interactions are at the moment.
15:31:57 <carl_baldwin> neiljerram: You mean what they currently are, or what they will be?
15:32:13 <neiljerram> carl_baldwin, What they are now.
15:32:32 <neiljerram> carl_baldwin, I suspect there are possibilities that I'm not yet aware of.
15:32:50 <carl_baldwin> neiljerram: Have you had a chance to read the Nova spec that I have up?
15:33:17 <carl_baldwin> mlavalle: Also, have you had a chance to review that one?
15:33:18 <neiljerram> carl_baldwin, Not yet; I'll do that.
15:33:43 <mlavalle> carl_baldwin: yes, I gave it a first pass yesterday. I intend to go over it again today
15:34:48 <carl_baldwin> neiljerram: It goes in to a little more detail.  It describes a few use cases for how an end user interactions.  For example, end user calls Nova boot with --net.  Or, end user calls Neutron to create a port with no IP address and calls boot with that port, etc.
15:35:06 <carl_baldwin> #link https://review.openstack.org/#/c/263898/
15:35:32 <carl_baldwin> It has gone without a meaningful review for a little while now and that concerns me.
15:36:27 <carl_baldwin> As for the current nova / neutron interactions, mlavalle is my goto guy.  :)
15:36:34 <neiljerram> Sorry!
15:37:03 <carl_baldwin> I learned quite a bit about it by reviewing his DNS code.
15:37:13 <mlavalle> carl_baldwin: yes, that is why I drew attention to it yesterday in the nova scheduler meeting
15:37:36 <mlavalle> carl_baldwin: I meant the spec
15:37:59 <mlavalle> carl_baldwin: maybe also I will attend the nova meeting on Tursday to start bringing it up
15:38:07 <carl_baldwin> mlavalle: I should have jumped in yesterday.  It was the end of an early meeting and I wasn't in a position to type.  But, I was surprised that they seemed to think it was new.
15:38:09 <mlavalle> Thursday^^^
15:38:58 <carl_baldwin> mlavalle: I wanted to tell them that this work was featured prominently at the Nova mid-cycle and was the subject of a rather long discussion.  Many of those guys were there.
15:39:31 <carl_baldwin> mlavalle: That would be great.  Let's not let them forget this spec is out there and is important to Neutron.
15:39:33 <carl_baldwin> :)
15:39:40 <mlavalle> carl_baldwin: let's remind them during the next their next meeting
15:40:48 <carl_baldwin> neiljerram: So, back to deferred IP allocation.  I think what we need is for someone to try it out.  But, to try it out, we might need the work that I haven't posted yet to attach subnets to segments.
15:41:06 <carl_baldwin> #action carl_baldwin will post work to link subnets and segments.
15:41:40 <carl_baldwin> neiljerram: Then, we need to defer IP allocation when the segment is not known until host binding and see how Nova reacts to that.
15:42:10 <carl_baldwin> mlavalle: ++
15:42:43 <neiljerram> carl_baldwin, Well I would hope that work on deferred IP allocation would _not_ be closely tied to segments.  So that it could be applicable to scenarios that don't use segments.
15:43:48 <carl_baldwin> neiljerram: Yes.  We just need to know what triggers deferred IP allocation in the non-segments case.
15:43:57 <neiljerram> carl_baldwin, Right.
15:44:11 <carl_baldwin> neiljerram: Because I don't think we want to defer for every port create.
15:44:21 <neiljerram> carl_baldwin, Agreed.
15:44:35 <neiljerram> carl_baldwin, That would be a big change for lots of existing situations
15:44:49 <carl_baldwin> neiljerram: ++
15:45:23 <carl_baldwin> neiljerram: Right now, one trigger for deferred allocation is that all of the subnets are tied to segments and the segment is not known.  That doesn't have to be the only trigger.
15:45:44 <neiljerram> carl_baldwin, So for me I think next step is to think what that trigger should be.
15:45:57 <carl_baldwin> We could have another mechanism where IPAM itself triggers deferred allocation.
15:46:11 <carl_baldwin> neiljerram: I'm just thinking out loud here.
15:46:37 <neiljerram> Yes, I was just thinking the same.  If a particular driver wants to be host-dependent, it should have a property that says 'that means I need deferred allocation'
15:46:50 <neiljerram> IPAM driver, I meant there.
15:47:13 <carl_baldwin> neiljerram: Something along those lines is what I'm thinking too.
15:47:42 <neiljerram> Although I also wonder whether it might be interesting to look at Subnet/host mapping similar to the Segment/host mapping in the current spec.
15:48:19 <neiljerram> That could allow host/Subnet affinity in the core, separately with the connectivity implications of being a segment.
15:48:59 <carl_baldwin> neiljerram: I think you may be on to something.
15:49:13 <carl_baldwin> mlavalle: Are you following?
15:49:23 <mlavalle> carl_baldwin: yes
15:50:22 <carl_baldwin> neiljerram: So, a plugin / driver could provide an interface for host / subnet mapping?  It might go through segments and might not.  Is that kind of what you're thinking?
15:50:40 <neiljerram> carl_baldwin, yes, that's it.
15:51:00 <carl_baldwin> And, I think the hard vs soft boundaries may come in to play here.
15:51:58 <neiljerram> carl_baldwin, For Calico in particular that would work very nicely, because I guess much of the core code would be common with the segmented case, but we wouldn't have to write a pluggable IPAM driver.
15:53:17 <neiljerram> The boundaries question is interesting in the segmented case too, I think.  Can a VM on segment migrate to a host on another segment?
15:53:32 <carl_baldwin> neiljerram: At the moment, no.
15:53:49 <carl_baldwin> Migration would be limited to same segment.
15:53:57 <carl_baldwin> s/would/will/
15:54:20 <mlavalle> carl_baldwin: we need to tweak the spec, don't we?
15:55:35 <carl_baldwin> mlavalle: For the mapping part?  Let me think about it.  I don't want to stall the current spec.  This might just be a follow-on.
15:55:55 <carl_baldwin> mlavalle: I might want to consult with you later today to flesh this idea out.
15:56:12 <mlavalle> carl_baldwin: yeah..... for the mapping part.... ok, let's talk later
15:56:46 <carl_baldwin> mlavalle: It doesn't really change what we need around segment / host mapping in the short term.
15:56:55 <neiljerram> carl_baldwin, I'm sorry again for raising this so late - we've been focussing here on a release, for quite a while.  But I have time to help now.
15:56:56 <mlavalle> carl_baldwin: agree
15:57:20 <mlavalle> carl_baldwin: but is additional stuff that we need to do
15:58:07 <carl_baldwin> mlavalle: Right.  I think I want to go look at the segment aware DHCP patch too in this context.
15:58:36 <carl_baldwin> #action carl_baldwin will work out host / subnet mapping interface.
15:58:47 <carl_baldwin> Well, we're about out of time.  Anything else?
15:59:18 <mlavalle> carl_baldwin: not from me.... actually I need to go to another meeting :-)
15:59:28 <carl_baldwin> Thanks vikram_ obondarev mlavalle and neiljerram (did I forget anyone?)
15:59:40 <neiljerram> Thanks!
15:59:42 <vikram_> thanks
15:59:47 <mlavalle> thanks!
15:59:58 <carl_baldwin> Hope to see more next week.
16:00:01 <carl_baldwin> #endmeeting