18:01:02 #startmeeting networking_policy 18:01:03 Meeting started Thu Apr 27 18:01:02 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:04 hi! 18:01:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:07 The meeting name has been set to 'networking_policy' 18:01:07 hi 18:01:25 main agenda today is thomas’ dual stack spec 18:01:29 :) 18:01:43 #topic IP v4, v6 dual-stack support proposal 18:01:47 annak: rkukura: SumitNaiksatam; thanks for the comments! 18:01:50 #link https://review.openstack.org/458583 18:02:19 tbachman: np, rkukura deserves the majority :-) 18:02:26 SumitNaiksatam: ack! 18:02:37 FWIW, I’ve posted an updated version, based on the feedback/reviews 18:02:43 tbachman: so you had rightly brought up the external segment 18:02:47 more on there way ;) 18:02:53 rkukura: oh okay 18:02:53 rkukura: lol 18:03:06 rkukura: i thought you were done, i mean... 18:03:07 SumitNaiksatam: yeah — I wasn’t sure whether or not to address that in this spec 18:03:18 tbachman: i was thinking it shoud be a part of this 18:03:29 SumitNaiksatam: okay. I’ll add that in then 18:03:32 just a couple nits, and maybe one needing fixing (so far) 18:03:34 tbachman: i dont mean to prolong this, but i think it goes with this 18:03:43 SumitNaiksatam: agreed 18:03:54 sounds like I’ll need another iteration in any case ;) 18:03:58 rkukura: just kidding :-) thanks for the thorough review 18:04:32 annak: do you feel comfortable with this? 18:04:39 i mean the current iteration 18:05:09 SumitNaiksatam: sure, i was just giving a different perspective 18:05:26 annak: your point was very valid 18:05:41 tbachman: +1 18:05:51 perhaps we can keep it in mind for future 18:05:56 annak: definitely 18:06:43 I have one open issue with the proposed spec that maybe we could get consensus on here 18:06:45 annak: with the proposed changes, do you feel you will be able to incorporate them in your driver? 18:07:09 rkukura: okay go ahead, you first 18:07:10 SumitNaiksatam: I think so 18:07:14 annak: nice 18:07:24 after annak 18:07:41 annak: the point of this exercise is to make sure that all drivers can support this 18:07:42 I'm done :) 18:07:49 ok 18:07:50 annak: otherwise we need to rethink 18:08:45 rkukura: go ahead 18:08:59 So I’ve been arguiing that IPv4 subnets should always be allocated with the L3P’s subnet_prefix_length, even if that is different than the default_prefixlen of the IPv4 subnetpool from which it is being allocated. 18:09:42 I think this is important to allow the subnetpool (particularly for public addresses) to be widely shared - not everyone needs the same size subnets 18:10:31 rkukura: okay, i know we had a bit of discussion on this 18:10:32 So my thinking is that subnet_prefix_length should be used if it is between the subnetpool’s min_prefixlen and max_prefixlen. 18:11:14 It doesn’t seem this has been incorporated into the current draft, and some of the places where it says “subnet_prefix_length is ignored” would need updating. 18:11:17 rkukura: what did you think of my change for the L3P’s subnet_prefix_length is None? 18:11:38 Is that in the current draft tbachman ? 18:11:42 rkukura: i do still maintain that that model is but complicated for the user to understand 18:11:45 * tbachman thinks 18:12:16 rkukura: however, if you thnk that it satisfies a use case which we cannot otherwise support, we can go with that 18:12:33 SumitNaiksatam: I’m not trying to add complexity, and it might even make the model a bit more consistent 18:12:45 rkukura: okay, how so? 18:13:06 Especially with the resource_mapping driver, tuning the subnet size may be important 18:14:03 rkukura: looks like I left my addition out :( 18:14:06 I’ll have to add that in 18:14:26 It can be argued it would be more consistent if subnet_prefix_length is always used (if not None) when allocating IPv4 subnets is more consistent than sometimes using it during L3P creation, and sometimes completely ignoring it for IPv4 18:15:10 rkukura: okay 18:15:22 I do like the idea of None meaning “ignore it” 18:15:24 should there instead be an exception if the user’s provided a length that is outside the min/max ? 18:15:24 rkukura: and why is it more important for the resource_mapping driver? 18:15:34 tbachman: yes 18:16:38 I’m OK with either an exception when creating the L3P, or simply constraining the length by the subnetpool’s min and max when allocating from that pool. I think these subnetpool attributes are mutable. 18:17:25 rkukura: could you perhaps give some concrete example of the use case where this is important? with examples of subnets 18:17:26 rkukura: ack. That’s where it gets a bit trickier 18:17:41 So even if it looks OK when creating the L3P, the subnet_prefix_length could be outside the range when the subnetpool is actually used. 18:18:06 One option would be to ignore that subnetpool (allocation would fail I think) and move onto the next (if available) 18:19:20 Do others agree that when a subnetpool (implicit or not) is widely shared between different L3Ps and non-GBP neutron code, tuning the subnet size at the L3P granularity is important? 18:20:11 rkukura: so this is a case where multiple L3Ps map to the same/shared address-scope and subnetpool? 18:20:23 rkukura: here you’re referring to the possibility of there being multiple subnets in the pool? 18:20:43 SumitNaiksatam: yes 18:21:33 tbachman: I was referring above to the case where the L3P has multiple subnetpools, if that’s what you mean. A subnetpool generally can allocate many subnets (even of different sizes) 18:21:54 rkukura: right. We’re on the same page then 18:22:11 My understanding was this was a possible use case where multiple projects supply their own pools 18:22:12 rkukura: what you say makes sense in theory, but i am not familiar with a strong usecase requiring that (parding my ignorance here) 18:22:43 (sorry — own subnets to the pool, not own pools) 18:22:48 rkukura: of course, what you propose, is more flexible/granular 18:23:01 The problem with lots of subnetpools is that public address space is a very scarce resource, so splitting into many pools, each only partially used, is very wasteful 18:23:20 rkukura: sure 18:23:24 rkukura: agreed with public. Not so much with private. 18:23:34 tbachman: good point 18:23:58 I think its a better practice to widely share a single subnetpool (for public space at least) and allocate what’s needed, of the size needed, from it 18:24:33 rkukura: that sounds like a good practice. I’m not familiar enough with use cases to know whether or not that’s the way this works with cloud providers 18:24:38 (for private address space) 18:25:09 I can see there being a need for the flexibility of the customer providing their addressing needs 18:25:13 rkukura: it would have been ideal if the allocation was a little more predictable (for the user) 18:25:31 (where “customer” would be a tenant) 18:26:15 thats my recurring concern (but perhaps is trumped by the use requirement to provide the flexibility) 18:26:40 rkukura: I think you have a good point on being explicit of the behaviors here. I don’t believe my changes cover that well 18:28:45 i am wondering if there is a way we annotate which attribute was used to make the allocation? 18:28:47 Should we let tbachman try to include this in the updated spec, and see if we think it is usable enough? 18:29:41 If subnet_prefix_length is None, that means not to use it, and use the IPv4 subnetpool’s default_subnetlen instead. 18:29:47 in my iteration of the spec i was achieving this by setting certain attributes to None 18:29:58 rkukura: ah just saying that :-) 18:30:27 So setting it None “annotates” that the user does not want it used ;) 18:30:58 rkukura: right, yeah so if we can remove/reduce any ambiguity that way, it makes it a lot easier to consume 18:31:36 I think we just need the first part of the spec to focus on how the subnetpools and address scopes get created and/or associated with the L3P. Then the next part describes he subnets are allocated. 18:32:01 Not much change is needed - I have comments almost ready to post with most of them 18:32:41 rkukura: SumitNaiksatam: I’ll wait for the review comments, then update the spec accordingly 18:32:52 (along with what we’ve discussed here) 18:32:59 sounds good 18:34:09 tbachman: okay sure 18:34:09 rkukura: thanks 18:34:09 and tbachman thanks as well for shepherding this, it is pretty hairy 18:34:42 SumitNaiksatam: np! Had a lot of help from the work you did, as well as the reviews and comments by rkukura, annak, and yourself! 18:35:00 tbachman: rkukura: anything else you want to discuss on this? 18:35:07 #topic Open Discussion 18:35:17 SumitNaiksatam: I think I’m good 18:35:18 nothing else on the spec 18:35:54 want to highlight the work annak is doing in terms of bringing the project up to speed with neutron-lib 18:35:54 annak: thanks 18:35:54 here is another one: 18:36:07 #link https://review.openstack.org/#/q/topic:neutron_lib_db 18:36:38 i dont have anything else for today 18:37:01 one quick question for annak on those patches 18:37:36 rkukura: sure 18:38:21 for code that we plan to backport to stable/mitaka, will we need to edit the back-ports, or did these deprecations start in mitaka (or earlier)? 18:38:43 rkukura: these are mostly newton and beyond 18:38:48 I admit I haven’t looked yet 18:39:07 so we will need different code for mitaka vs. newer branches, OK 18:39:22 just wanted know what to expect 18:39:38 rkukura: at this point i am not expecting mitaka backports for these 18:39:39 I'm not sure, I think I started seeing deprecations in newton 18:39:58 rkukura: i mean most of them are not relevant for mitaka 18:40:00 annak: right 18:40:38 My point is simply that new code being written (for stable/newton compatibility) that avoids the deprecations may need modification when back-ported to stable/mitaka, if the new APIs were not in mitaka 18:41:01 rkukura: yeah backports to mitaka are becoming messy 18:41:35 most of the changes are in imports, so its not that bad 18:41:37 but not all 18:41:42 rkukura: for instance, i am not backporting any of the notifications’ latest changes to mitaka 18:41:59 rkukura: because not all of it is applicable 18:42:20 SumitNaiksatam: Sure, but I believe the IPv6 work tbachman and I are doing will need to be back-ported to mitaka 18:42:51 rkukura: yeah, i hope its not messy! 18:43:38 alrighty, lets wrap it up for today then! 18:43:43 thanks all for joining 18:43:47 SumitNaiksatam: thanks! 18:43:53 thanks! bye 18:43:55 bye 18:44:00 #endmeeting