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