18:01:20 <SumitNaiksatam> #startmeeting networking_policy
18:01:21 <openstack> Meeting started Thu May  4 18:01:20 2017 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:24 <openstack> The meeting name has been set to 'networking_policy'
18:01:39 <SumitNaiksatam> same agenda as last time, focus on the dual stack spec
18:01:45 <tbachman> :)
18:01:46 <SumitNaiksatam> #topic IP v4, v6 dual-stack support proposal
18:01:52 <SumitNaiksatam> #link https://review.openstack.org/458583
18:01:58 <SumitNaiksatam> tbachman: thanks for the updates
18:02:02 <tbachman> SumitNaiksatam: np!
18:02:06 <tbachman> Thanks for the reviewS!
18:02:23 <tbachman> So, I think we’re getting close here
18:02:30 <SumitNaiksatam> much appreciate the effort in trying to pull in all the comments and approach consensus
18:02:34 <tbachman> np!
18:02:36 <SumitNaiksatam> tbachman: definitely
18:02:47 <SumitNaiksatam> i was hoping we would have closed this in today’s meeting
18:02:47 <tbachman> I’m going to update the spec with some slight changes
18:02:57 <SumitNaiksatam> but we dont have rkukura, but i think we got his comments
18:03:23 <tbachman> in order to maintain backward-compatibility, I’m proposing that the ip_pool parameter be changed from a subnet to a string
18:03:26 <SumitNaiksatam> annak: not sure you got a chance to look at the latest iteration, but i think there should not  be any surprises
18:03:31 <tbachman> (in the RESOURCE_ATTRIBUTE_MAP)
18:03:31 <SumitNaiksatam> tbachman: right
18:03:49 <tbachman> and for multiple prefixes, we’ll just use a string that has prefixes delimited by commas
18:04:04 <SumitNaiksatam> annak: if anything, this is ensures even more that we dont break any compatibility
18:04:10 <annak> SumitNaiksatam: I didn't quite understand the latest rkukura's comment about dependency on the ml2 plugin
18:04:18 <SumitNaiksatam> annak: ah
18:04:23 <SumitNaiksatam> that one is a little confusing
18:04:32 <tbachman> (e.g. two prefixes would be specified via ‘192.168.0.0/16, 2001:db8:1::/64’, instead of [‘192.168.0.0/16’, ‘2001:db8:1::/64’]
18:04:36 <tbachman> ah yes
18:04:39 <SumitNaiksatam> regarding the default subnetpool
18:04:44 <SumitNaiksatam> tbachman: may be you can elaborate
18:04:51 <tbachman> SumitNaiksatam: sure!
18:05:06 <tbachman> So, we were trying to enhance the implicit behavior
18:05:17 <tbachman> to enable implicit v4 and v6 subnets
18:05:40 <tbachman> initially we proposed using the implicit subnetpool extension, which was added to neutron
18:05:50 <tbachman> but that’s sort of non-standard neutron semantics
18:05:59 <SumitNaiksatam> tbachman: added to GBP you mean?
18:06:08 <tbachman> SumitNaiksatam: ack
18:06:09 <tbachman> sorry
18:06:19 <tbachman> added to GBP, but for neutron workflow, I believe
18:06:29 <tbachman> (or that was my understanding from rkukura)
18:06:37 <SumitNaiksatam> tbachman: right
18:06:44 <tbachman> rkukura pointed that out — and recommended the idea of using the existing default subnetpools in neutron instead
18:06:44 <SumitNaiksatam> annak: we are referring to this: #link https://review.openstack.org/#/c/419315/
18:06:52 <tbachman> SumitNaiksatam: thx for the link!
18:07:16 <SumitNaiksatam> tbachman: agree with that, my concern was that implicit subnetpool is ml2plus specific
18:07:30 <tbachman> SumitNaiksatam: ack
18:07:53 <SumitNaiksatam> annak: are you familiar with the default subnetpool in neutron?
18:07:57 <tbachman> Right — SumitNaiksatam: thanks for pointing that out!
18:08:11 <annak> SumitNaiksatam: no, it looks fairly recent
18:08:18 <SumitNaiksatam> annak: ah okay
18:08:40 <SumitNaiksatam> tbachman: perhaps a little bit background on that as well :-P
18:08:43 <tbachman> lol
18:08:54 <tbachman> I can’t recall the exact reason for that — was it for the “get me a network” workflow?
18:09:02 <SumitNaiksatam> tbachman: thats correct
18:09:02 <tbachman> (in neutron)
18:09:04 <tbachman> k
18:09:24 <tbachman> The idea is similar to the implicit subnetpool extension that we added to GBP
18:09:57 <tbachman> where someone (e.g. an admin) could create a subnetpool and declare it as a “default” pool that others could use for allocation if they didn’t want to declare/specify this themselves
18:10:11 <tbachman> However, with the default subnetpools, you had to “opt-in"
18:10:31 <tbachman> meaning you had to specify that you wanted allocation from the default subnetpool — this would not happen without indicating such
18:10:32 <SumitNaiksatam> annak: basically default subnetpool for the legacy usage behavior (where the user is not aware of subnetpools, but the admin still wants subnetpools to be used)
18:11:11 <SumitNaiksatam> tbachman: ah correct, so might have to amend by statement a bit (about the user not being aware)
18:11:32 <tbachman> the difference between that and the implicit subnetpool extension is that the user would not have to specify the opt-in — they would get an allocation even if they didn’t specify it
18:11:43 <tbachman> (assuming that they didn’t provide a prefix explicitly)
18:11:48 <SumitNaiksatam> tbachman: nice summary!
18:12:15 <annak> thanks! that clarifies a lot, but the plugin dependency part is still missing :)
18:12:16 <tbachman> for neutron workflow, that is the difference
18:12:20 <tbachman> ah
18:12:26 <SumitNaiksatam> annak: but implicit subnetpool is only being used by ml2plus
18:12:35 <tbachman> SumitNaiksatam: was just about to type that :)
18:12:36 <tbachman> thx!
18:12:59 <SumitNaiksatam> annak: so for example, in your case, where you are probably using a monolithic neutron plugin, you will not be leveraging this feature
18:13:14 <SumitNaiksatam> (or rather the extension)
18:13:17 <SumitNaiksatam> and hence the concern
18:13:32 <annak> okay, that's because other plugins didn't adopt the extension?
18:13:34 <SumitNaiksatam> songole: hi
18:13:53 <tbachman> annak: right. We’d like to use standard neutron constructs, where available
18:13:55 <SumitNaiksatam> annak: thats because the “implicit subnetpool” extension is defined in GBP :-)
18:13:58 <songole> hi
18:14:13 <SumitNaiksatam> annak: its a neutron extension but defined in the GBP repo
18:14:23 <SumitNaiksatam> annak: so yes, other plugins as obviously not using it
18:14:26 <tbachman> For GBP, we were basically already defining the implicit “opt-in”, so we can therefore instead explicitly opt-in with default subnetpools
18:14:43 <annak> now I understand :) thanks
18:14:46 <SumitNaiksatam> tbachman: right
18:14:50 <tbachman> annak: gr8! :)
18:15:19 <tbachman> I think there are basically now 3 main workflows with the new APIs
18:15:33 <tbachman> 1) The user passes in the subnetpools and address scopes explicitly (v4, v6, or dual-stack)
18:15:41 <SumitNaiksatam> annak: hence tbachman’s point for actually using neutron’s default subnetpool feature to achieve the same thing, so that its consistent across neutron plugins that are used in the GBP context
18:15:44 <annak> sorry to take so much time on this, but are the aim and apic plugin normally working above ml2?
18:16:09 <tbachman> annak: apic_mapping uses ML2. AIM uses ML2 Plus.
18:16:25 * tbachman hopes SumitNaiksatam will correct tbachman if he’s wrong on that
18:16:34 <SumitNaiksatam> tbachman: thats very correct
18:16:52 <SumitNaiksatam> annak: ml2plus is basically ml2 with a few enhancements
18:17:01 <annak> tbachman: thanks, I just assumed cisco-specific plugins there
18:17:24 <SumitNaiksatam> annak: the enahncements are made such that we can achieve transactional consistency
18:17:36 <tbachman> annak: keep in mind that others using the ml2plus plugin would also have access to these things
18:17:52 <tbachman> (i.e. tried to keep things generic)
18:17:54 <SumitNaiksatam> annak: so you yeah you can think of it as another monolithing plugin, but potentially others can use it as well
18:18:05 <SumitNaiksatam> tbachman: nice
18:18:24 <tbachman> 2) the user passes in one or more prefixes via the ip_pool parameter, but no subnetpools, etc. In this case, the prefixes will be used to create subnetpools and addres scopes implicitly
18:18:29 <annak> that was a big missing part in my head :) thanks for clarifying that
18:18:58 <tbachman> 3) the user doesn’t pass in any prefix, but a default subnetpool was created; in this case, the default subnetpool is associated with the L3P, and subnets are allocated from it
18:19:07 <tbachman> I think those will be the main workflows
18:19:12 <SumitNaiksatam> tbachman: nice
18:19:14 <SumitNaiksatam> summary
18:19:27 <SumitNaiksatam> (and sorry for interrupting your train of thought earlier)
18:19:28 * tbachman notes there are some details in there, and is happy to field questions on said details :)
18:19:33 <tbachman> SumitNaiksatam: no, no worries!
18:19:43 <SumitNaiksatam> (annak ml2plus #link https://github.com/openstack/group-based-policy/blob/master/gbpservice/neutron/plugins/ml2plus/plugin.py)
18:20:07 <tbachman> SumitNaiksatam: thanks for filling in the details as well!
18:20:23 <SumitNaiksatam> tbachman: these three are captured in the spec update, right?
18:20:33 <SumitNaiksatam> i mean they are enumerated like this, right?
18:20:38 <tbachman> SumitNaiksatam: if they aren’t, I’ll make sure that they are :)
18:20:43 <SumitNaiksatam> tbachman: thanks
18:20:49 <tbachman> SumitNaiksatam: np!
18:21:22 <SumitNaiksatam> tbachman: yeah, clearly laying out like this definitely makes it easier for people to get the larger context
18:21:43 <SumitNaiksatam> the spec has two aspects, the api design, and the implementaion design
18:21:51 <SumitNaiksatam> not everyone is interested in the latter :-)
18:22:23 <SumitNaiksatam> and as devs we end up focussing on the latter
18:22:42 <tbachman> SumitNaiksatam:  ack
18:22:56 <SumitNaiksatam> tbachman: so going back to the implicit/default subnetpools
18:23:20 <SumitNaiksatam> so we are saying now that GBP will internally always use the “default subnetpools” neutron feature?
18:23:43 <tbachman> SumitNaiksatam: I think that’s the proposal, yes
18:24:36 <SumitNaiksatam> tbachman: okay, just want to spell out to understand how it works for annak
18:24:54 <SumitNaiksatam> because with that implementation we would always be creating a subnetpool for l3p, right?
18:25:03 <annak> SumitNaiksatam: thanks!
18:25:16 <tbachman> SumitNaiksatam: only if there is a default subnetpool defined, yes
18:25:43 <SumitNaiksatam> tbachman: hmm okay, so GBP doesnt create it
18:25:50 <SumitNaiksatam> i mean the default subnetpool
18:26:09 <tbachman> SumitNaiksatam: I was thinking that would/should be a workflow decision
18:26:13 <tbachman> but am open to thoughts there
18:26:15 <SumitNaiksatam> makes sense
18:26:31 <tbachman> That ends up being important for the implicit workflow
18:26:46 <tbachman> Where you want all v6 addresses allocated from the same scope
18:26:48 <SumitNaiksatam> so there is still a way to opt out of this behavior, and you get the best of both
18:26:49 <tbachman> so that they’re all routable
18:26:55 <tbachman> SumitNaiksatam:  ack
18:26:58 <SumitNaiksatam> tbachman: right
18:27:23 <tbachman> So, if someone has bothered to create a v6 subnetpool from an address scope and marked it as default
18:27:50 <tbachman> if they create an L2P using implicit workflow, the L3P will make sure that it uses this pool and all v6 addresses for that L3 would be allocated from it
18:27:58 <SumitNaiksatam> tbachman: so i guess there should not be any cause for alarm for annak even if she is not using subnetpools, right?
18:28:26 <tbachman> you mean explicit subnetpools?
18:28:30 <tbachman> Or no subnetpools at all?
18:28:47 <tbachman> (i.e. some other mapping)
18:29:01 <SumitNaiksatam> tbachman: i meant to say no subnetpools at all, but annak can correct me
18:29:13 <annak> no subnet pools at all at this point
18:29:18 <SumitNaiksatam> tbachman: i am saying because today resource mapping is not using the subnetpools
18:29:23 <SumitNaiksatam> annak: right
18:29:25 <tbachman> ah, right
18:29:35 <tbachman> I guess that’s a different question
18:29:39 <SumitNaiksatam> and hence i assumed annak is not using it
18:31:10 <SumitNaiksatam> tbachman: to reframe my question, with the changes that are being proposed, would it immediately break anything in the current state of the resource mapping driver?
18:31:37 <tbachman> SumitNaiksatam: no.
18:31:43 <annak> I currently inherit the resource mapping behavior for the connectivity. I plan to try and use them as part of resource mapping in future, I think thats what we want anyway?
18:32:02 <tbachman> annak: I think so
18:32:03 <SumitNaiksatam> in general, we need to move the resource mapping driver to use subnetpools as well, but thats a separate pursuit (which actually should be not be that big an effort)
18:32:12 <tbachman> SumitNaiksatam: +1
18:32:28 <SumitNaiksatam> tbachman: thanks for confirming that
18:32:52 <tbachman> SumitNaiksatam: np!
18:33:39 <SumitNaiksatam> tbachman: so to summarize, the entire discussion from a backward compat perspective, and in terms of continued usage or extension of the resource mapping driver,
18:34:10 <SumitNaiksatam> there are potentially two places where there will be a slight bit of incompatibility
18:34:48 <SumitNaiksatam> 1. you might start seeing a list of comma separated CIDRs in the ip_pool
18:35:11 <tbachman> (nit: string of comma-separated CIDRs ;-)
18:35:59 <SumitNaiksatam> tbachman: ack, thanks :-)
18:36:42 <SumitNaiksatam> i was going to comment about the subnet_prefix_length, but i guess nothing changes there, right?
18:36:54 <tbachman> SumitNaiksatam: ack — we’re holding off on that for now
18:36:55 <tbachman> Oh
18:36:58 <SumitNaiksatam> i mean with the current iteration
18:36:59 <tbachman> The DB field
18:37:01 <SumitNaiksatam> yeah
18:37:09 <tbachman> forgot about that
18:37:20 <SumitNaiksatam> tbachman: right
18:37:37 <tbachman> in order to accommodate multiple prefixes, the DB entry for ip_pool should be upped — from a String(64) to something like String(256)
18:37:54 <SumitNaiksatam> but thats not necessarily backward incompatibility
18:38:09 <tbachman> SumitNaiksatam: ack
18:38:14 <tbachman> just another thing to note
18:38:15 <SumitNaiksatam> since it wont break anything for anyone not aware of it
18:38:18 <SumitNaiksatam> tbachman: sure
18:38:20 <tbachman> I’ll update the spec with that as well
18:38:26 <SumitNaiksatam> thanks
18:38:42 <SumitNaiksatam> i see songole is back, perhaps a few minutes of NFP discussion now
18:38:52 <SumitNaiksatam> assuming we are done with the dual stack discussion
18:39:05 <SumitNaiksatam> annak: any more questions/comments on this?
18:39:10 <tbachman> SumitNaiksatam: I think that’s all I had
18:39:19 <SumitNaiksatam> tbachman: thanks much
18:39:24 <tbachman> SumitNaiksatam: np!
18:39:26 <annak> SumitNaiksatam: no, I'm good, thanks.
18:39:31 <SumitNaiksatam> annak: great
18:39:43 <SumitNaiksatam> based on the discussion so far i am inclined to +2 tbachman’s next iteration
18:39:51 <tbachman> :)
18:39:56 <SumitNaiksatam> if there are any concerns, they can be expressed on the review
18:40:03 <SumitNaiksatam> i dont have any at this point
18:40:37 <SumitNaiksatam> hopefully we can have agreement with other cores and move forward quickly
18:40:53 <SumitNaiksatam> it should be noted that tbachman you already have the impl patch in review, right?
18:41:05 <tbachman> SumitNaiksatam: ack. But I have some changes to make
18:41:12 <SumitNaiksatam> tbachman: okay
18:41:13 <tbachman> I’m hoping to upload those sometime tonight
18:41:45 <SumitNaiksatam> songole: i am guessing that you dont have any objections to the dual stack proposal?
18:42:10 * tbachman notes that ip_pool is used in services too, I believe
18:42:16 <songole> SumitNaiksatam: I haven't gone through the proposal. Will do it.
18:42:17 <tbachman> proxy
18:42:28 <SumitNaiksatam> songole: oh okay, please do :-)
18:42:35 <SumitNaiksatam> tbachman: right
18:42:58 <SumitNaiksatam> tbachman: i cant imagine we are breaking anything with that, but worth a sanity check from songole
18:43:23 <SumitNaiksatam> songole: we are kind of behind on this, so a quick read at the earliest will be appreciated
18:43:28 <tbachman> SumitNaiksatam: ack. The UTs passed the first iteration. I will make sure they pass the secon one as well.
18:43:33 <songole> SumitNaiksatam: ok
18:43:36 <SumitNaiksatam> tbachman: thanks :-)
18:43:41 <tbachman> songole: you may want to wait for my update
18:43:45 <tbachman> I’ll expedite that
18:43:48 <SumitNaiksatam> tbachman: good point
18:43:57 <songole> tbachman: okay
18:43:58 * tbachman puts on his rocket shoes
18:44:01 <tbachman> lol
18:44:02 <SumitNaiksatam> tbachman: annak: thanks for the discussion on this
18:44:05 <SumitNaiksatam> tbachman: lol!
18:44:13 <SumitNaiksatam> #topic NFP patches
18:44:27 <SumitNaiksatam> songole: i provided some review comments on the outstanding patches (on async)
18:44:32 <SumitNaiksatam> i am happy to discuss here
18:44:47 <annak> I need to leave, thanks for all the explanations!
18:44:54 <tbachman> annak: thanks for the input!
18:45:27 <songole> SumitNaiksatam: one suggestion you made https://review.openstack.org/#/c/445425/20/gbpservice/neutron/services/grouppolicy/drivers/chain_mapping.py@105
18:45:47 <songole> can that be taken up as an enhancement/fix later?
18:45:55 <SumitNaiksatam> songole: yeah, i am really not comfortable with the way its implemented currently
18:46:22 <SumitNaiksatam> songole: i dont think its a big change to move the model i suggested, it should be fairly quick
18:46:34 <SumitNaiksatam> songole: do you anticipate an issue with making that change?
18:46:59 <songole> SumitNaiksatam: I am afraid that people are going on long summer vacation :)
18:47:24 <SumitNaiksatam> songole: you mean the author is not vacation right now?
18:47:28 <songole> and this requires decent amount of work
18:48:24 <songole> what is the issue with the fix? perhaps we can catch up offline
18:48:27 <SumitNaiksatam> songole: thats my point, it doesnt require too much work, its just refactoring of a few methods in that same module
18:49:04 <SumitNaiksatam> songole: the issue is that this kind of introspection is brittle, and much cleaner and easier option exists
18:49:44 <songole> ok
18:50:07 <SumitNaiksatam> songole: unless i am missing some basic issue which the author ran into (but rajendra’s review comments do not suggest that)
18:51:07 <SumitNaiksatam> songole: lets discuss the logistics offline (vacations issues etc)
18:51:22 <songole> ok
18:51:33 <SumitNaiksatam> songole:  anything to discuss with the other patches?
18:52:04 <songole> They posted a patch for delete. could you review it?
18:52:16 <SumitNaiksatam> songole: yeah
18:52:33 <SumitNaiksatam> songole: i was hoping to see UTs in this: https://review.openstack.org/#/c/438472
18:52:46 <SumitNaiksatam> because currently the code is not getting exercised
18:53:03 <SumitNaiksatam> i saw the delete patch earlier, but the a bunch of jobs are breaking
18:53:15 <SumitNaiksatam> hence i was not sure if it was still WIP
18:53:19 <songole> yeah
18:54:03 <SumitNaiksatam> songole: seems like the nfp gate job is good now, finishing in an hour, thats great!
18:54:32 <songole> SumitNaiksatam: it still fails inconsistently. rajendra is looking into it
18:54:39 <SumitNaiksatam> songole: right, i did see it fail
18:55:09 <SumitNaiksatam> songole: thanks for looking into it!
18:55:19 <songole> SumitNaiksatam: np
18:55:25 <SumitNaiksatam> songole: thanks for the discusison on this (and we can continue offline)
18:55:31 <SumitNaiksatam> #topic Open Discussion
18:55:48 <SumitNaiksatam> tbachman: annak songole: we will not have the meeting next week since its summit week
18:55:54 <tbachman> SumitNaiksatam: akc
18:55:55 <tbachman> ack
18:56:14 <SumitNaiksatam> unfortunately i wont be able to make it to the summit
18:56:26 <SumitNaiksatam> annak: tbachman you mentioned you are not going either
18:56:35 <tbachman> SumitNaiksatam: right, can’t make it this time
18:56:35 <SumitNaiksatam> songole: i dont think you are going either
18:56:52 <SumitNaiksatam> tbachman: is rkukura going?
18:57:03 <SumitNaiksatam> earlier he had mentioned he was not going to be in boston during that time
18:57:03 <songole> SumitNaiksatam: nope, I am not going either
18:57:04 <tbachman> SumitNaiksatam: I think for some of it
18:57:12 <SumitNaiksatam> tbachman: okay
18:57:14 <SumitNaiksatam> songole: okay
18:57:15 <tbachman> I seem to recall he won’t be there Monday
18:57:21 <SumitNaiksatam> tbachman: okay
18:57:47 <SumitNaiksatam> so rkukura will carry our flag at least for some of the summit :-)
18:58:02 <SumitNaiksatam> we can stil meet next week if required (since most of us are not going)
18:58:09 <tbachman> :)
18:58:16 <SumitNaiksatam> but for now the meeting stands cancelled unless you see an email from me
18:58:35 <SumitNaiksatam> anything else for today?
18:58:59 <SumitNaiksatam> alrighty, thanks all for joining!
18:59:03 <tbachman> SumitNaiksatam: thx!
18:59:08 <SumitNaiksatam> bye!
18:59:12 <SumitNaiksatam> #endmeeting