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