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