18:01:28 <SumitNaiksatam> #startmeeting networking_policy 18:01:29 <openstack> Meeting started Thu Apr 20 18:01:28 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:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:32 <openstack> The meeting name has been set to 'networking_policy' 18:01:52 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#April_20th_2017 18:02:18 <rkukura> hi 18:02:24 <SumitNaiksatam> rkukura: hi 18:02:27 <SumitNaiksatam> so first up, the py27 gate job is broken, again 18:02:38 <tbachman> :( 18:02:43 <SumitNaiksatam> this time its because of a change in the “aim” dependency 18:03:22 <SumitNaiksatam> some of us are trying to figure out the best way to fix this, and also how changes in aim repo dont immediately impact us in the future 18:03:43 <SumitNaiksatam> please hang in there, and apologies for the delay in getting this fixed! 18:04:23 <SumitNaiksatam> also, there were some backports in Neutron which broke our gate a couple of days back 18:04:35 <SumitNaiksatam> that has been fixed, if you would like to know more ping me offline 18:04:39 <SumitNaiksatam> songole: hi 18:04:51 <songole> SumitNaiksatam: hello 18:04:55 <SumitNaiksatam> #topic IP v4, v6 dual-stack support proposal 18:05:02 <SumitNaiksatam> tbachman: over to you 18:05:09 <SumitNaiksatam> #link https://review.openstack.org/458583 18:05:10 * tbachman waves 18:05:22 <tbachman> so, I’m working on adding dual-stack support 18:05:35 <SumitNaiksatam> i dont think there was enough time for people to notice this, but we can still have the discussion 18:05:42 <SumitNaiksatam> tbachman: thanks for putting up the proposal 18:05:49 <tbachman> the original spec created by SumitNaiksatam covers the original goals pretty well 18:05:52 <SumitNaiksatam> rkukura: thanks for the offline discussions as well 18:05:53 * tbachman goes to get the original spec 18:05:55 <tbachman> SumitNaiksatam: thx! 18:06:19 <tbachman> Here is the original spec: 18:06:20 <tbachman> https://review.openstack.org/#/c/343929/ 18:06:23 <tbachman> #link https://review.openstack.org/#/c/343929/ 18:06:47 <tbachman> My patch amends this spec, as the original didn’t call out specifics for dual-stack support 18:06:50 <SumitNaiksatam> tbachman: so there is some API change involved, right? 18:07:00 <tbachman> (it mentions adding the groundwork for it though) 18:07:00 <tbachman> SumitNaiksatam: ack 18:07:07 <tbachman> the big changes from a semantics standpoint are: 18:07:22 <tbachman> 1) the ip_version property of the L3 policy has two new values 18:07:37 <tbachman> currently it supports ‘4’ for IPv4, and ‘6’ for Ipv6 18:07:55 <tbachman> now we want to add ’46’ and ’64’ as two possibilities for indicating dual-stack support 18:08:16 <SumitNaiksatam> tbachman: so we can characterize this as a backward compatible change, right? 18:08:18 <tbachman> 2) the semantics of the implicit subnetpool extension are amended, in order to account for address family 18:08:26 <tbachman> SumitNaiksatam: I believe so. That was the goal 18:08:44 <SumitNaiksatam> tbachman: thanks, and I was referring to the API change in (1) 18:09:04 <SumitNaiksatam> annak: songole: request you to take a look at this change 18:09:27 <rkukura> One of my comments on this spec is that having multiple values meaning the same thing (46 and 64) is not ideal. 18:09:28 <songole> SumitNaiksatam: okay 18:09:36 <SumitNaiksatam> rkukura: okay 18:09:38 <tbachman> rkukura: a fair point 18:09:42 <SumitNaiksatam> rkukura: but why? 18:09:45 <annak> SumitNaiksatam: sure 18:09:47 <rkukura> but lets discuss that in the gerrit review - other ideas are welcome 18:09:52 <SumitNaiksatam> rkukura: okay 18:10:12 <rkukura> because all code needs to check for both possible values 18:10:30 <rkukura> we could all both inputs, then normalize to one, but this just adds complexity 18:10:39 <rkukura> I’d prefer to settle on one value, such as 10 18:10:44 <SumitNaiksatam> rkukura: right, i was thinking that internally we can use one 18:10:53 <SumitNaiksatam> rkukura: not 12? ;-) 18:11:33 <SumitNaiksatam> tbachman: sorry to interrupt you 18:11:39 <tbachman> SumitNaiksatam: no worries :) 18:11:44 * tbachman grabs his popcorn 18:12:07 <tbachman> SumitNaiksatam: wasn’t sure if you wanted me to touch on anything else wrt the spec patch 18:12:36 <SumitNaiksatam> tbachman: this is summary is good, just asking in case you wanted to go into any more details right now 18:12:51 <SumitNaiksatam> tbachman: i still need to spend some more time reading it 18:13:03 <SumitNaiksatam> so one thing that rkukura brought up during the discussion was that the resource mapping driver is still not using address scopes and subnetpools 18:13:38 <SumitNaiksatam> the implementation is present but is not being used 18:13:45 <tbachman> SumitNaiksatam: great point 18:13:54 <tbachman> We will want/need to bring that up to spec 18:14:02 <SumitNaiksatam> annak: do you have a need to leverage the l3_policy to address_scope and subnetpool mapping? 18:14:03 * tbachman adds it to the list 18:14:10 <SumitNaiksatam> tbachman: thanks 18:14:25 <igordcard> hi all 18:14:26 <tbachman> SumitNaiksatam: shall I cover the implicit subnetpool feature ? 18:14:30 * tbachman waves to ig0r_ 18:14:32 <tbachman> oops 18:14:34 <tbachman> igordcard: 18:14:39 <SumitNaiksatam> igordcard: hi there, thanks for joining 18:14:40 <tbachman> ig0r_: wrong Igor ;) 18:14:46 <annak> SumitNaiksatam: I'm using l3 policy as is now (inherited from resource mapping) 18:14:58 <igordcard> tbachman: ahah 18:15:15 <SumitNaiksatam> annak: okay, may be we need to discuss this a little more, perhaps offline 18:15:42 <SumitNaiksatam> annak: just want to make sure you are aware of what the options are, because it might not be clear from the resource mapping implementation 18:15:44 <annak> SumitNaiksatam: okay, lets discuss, perhaps I can take the task 18:15:56 <annak> SumitNaiksatam: i need to read more about address scopes 18:16:19 <SumitNaiksatam> annak: yes sure 18:16:56 <SumitNaiksatam> so I want to give some time to igordcard before he has to take off 18:17:00 <SumitNaiksatam> tbachman: anything more on this today? 18:17:45 <SumitNaiksatam> okay moving on to QoS 18:17:50 <tbachman> SumitNaiksatam: I’ll wait for the comments in the gerrit 18:17:57 <tbachman> SumitNaiksatam: thx! 18:17:58 <SumitNaiksatam> tbachman: great thanks 18:18:00 <SumitNaiksatam> #topic QoS via NSPs patch 18:18:06 <SumitNaiksatam> #link https://review.openstack.org/#/c/426436 18:18:16 <SumitNaiksatam> rkukura: you had some good comments 18:18:28 <SumitNaiksatam> igordcard: wanted your quick input so that we can close on this patch 18:18:41 <rkukura> right 18:18:50 <igordcard> yep I'll try to address them today 18:18:58 <rkukura> a couple nits about whether burst is a rate vs a size 18:19:15 <rkukura> another couple questions/issues about the devstack support 18:19:50 <rkukura> and the local_api stuff seems to treat creating and updating qos policy inconsistently 18:20:46 <rkukura> finally, the DB schema has the qos policy as a primary key field, which seems to imply a many-to-many mapping, which I don’t think is what we have 18:20:46 <igordcard> thanks rkukura 18:21:05 <rkukura> I think these are all easily fixable 18:21:22 <SumitNaiksatam> rkukura: thanks for catching those 18:21:27 <igordcard> rkukura: the kb/kbps part is supposed to be like that, even though I'm reading the qos page now and it seems to be kbps/kbps now - I'll investigate further 18:21:33 <SumitNaiksatam> igordcard: perhaps some of those just need clarification 18:21:59 <rkukura> right, I thought burst was a size, until I looked at the qos.py extension definition again 18:22:30 <rkukura> I apologize that I didn’t get through as much as I had thought in my previous round of review 18:23:17 <SumitNaiksatam> this time around lets really try to merge this patch one the comments are addressed, igordcard much appreciate your patience in sticking around with this 18:23:40 <igordcard> thanks again rkukura I'll address everything soon 18:23:47 <igordcard> SumitNaiksatam: yey :D 18:23:52 <rkukura> great, I’m ready to re-review 18:24:04 <SumitNaiksatam> okay moving on 18:24:43 <SumitNaiksatam> igordcard: feel free to take off if its late for you 18:24:56 <igordcard> SumitNaiksatam: thanks 18:24:57 <igordcard> cya all 18:25:01 <tbachman> igordcard: l8r! 18:25:11 <SumitNaiksatam> #topic NFP patches 18:25:13 <rkukura> right - ping me or email if you want to discuss any of the comments 18:25:18 <SumitNaiksatam> songole: still there 18:25:20 <SumitNaiksatam> ? 18:25:52 <songole> Yes 18:26:09 <SumitNaiksatam> songole: sorry for holding up the patches 18:26:43 <songole> We are blocked on a couple of things 18:26:52 <SumitNaiksatam> songole: yes we can discuss here 18:27:12 <songole> mitaka: AIM tests are failing 18:27:25 <SumitNaiksatam> songole: yes, we will fix those today, asap 18:27:52 <songole> GBP async: waiting for ACI validation 18:28:15 <SumitNaiksatam> songole: hmmm okay, so what is the plan on how we want to do this? 18:28:54 <songole> I meant NFP async changes - we were asked to hold until Cisco release happens 18:29:05 <SumitNaiksatam> songole: right, NFP changes 18:29:30 <SumitNaiksatam> songole: i think we are past that point, at least to the extent i know 18:29:42 <SumitNaiksatam> songole: perhaps we can sync offline 18:29:49 <songole> okay 18:29:54 <SumitNaiksatam> songole: do the gate tests cover the async model? 18:30:13 <SumitNaiksatam> i mean exercise it 18:30:19 <songole> yes - as part of that patch 18:30:39 <SumitNaiksatam> great, and i meant the integration tests 18:31:27 <SumitNaiksatam> songole: so currently no blocker in terms of implemenation for you, the implementation/patches are ready, right? 18:31:46 <songole> yes 18:31:53 <SumitNaiksatam> songole: okay good 18:32:05 <SumitNaiksatam> songole: anything else you wanted to bring up today? 18:32:34 <songole> Nothing more.. 18:32:43 <SumitNaiksatam> songole: thanks 18:32:45 <SumitNaiksatam> #topic Open Discussion 18:32:55 <SumitNaiksatam> annak: thanks for posting this: https://review.openstack.org/#/c/458264 18:33:25 <annak> SumitNaiksatam: np, it doesn't eliminate all deprecations though 18:33:33 <SumitNaiksatam> getting rid of the deprecated warnings and bringing the code up-to-speed is definitely a top priority for the project 18:33:56 <SumitNaiksatam> annak: sure, but definitely a good step forward 18:34:05 <SumitNaiksatam> anything else for today? 18:34:09 <rkukura> Yes, and making it easier to find the useful log info 18:34:13 <rkukura> I’ll review today 18:34:25 <SumitNaiksatam> rkukura: true 18:34:35 <SumitNaiksatam> anything else anyone wanted to bring up? 18:34:52 <rkukura> nothing from me 18:34:59 <tbachman> SumitNaiksatam: I’m good 18:35:02 <SumitNaiksatam> all righty, thanks all for joining! 18:35:08 <tbachman> SumitNaiksatam: thx! 18:35:09 <SumitNaiksatam> bye! 18:35:13 <SumitNaiksatam> #endmeeting