18:03:28 #startmeeting networking_policy 18:03:29 Meeting started Thu May 18 18:03: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:03:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:32 The meeting name has been set to 'networking_policy' 18:04:12 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#May_18th_2017 18:04:31 perhaps we can switch the order of the agenda 18:05:35 ah there is annak, right on cue :-) 18:05:39 annak: hi 18:05:51 hi, sorry i'm a bit late 18:05:51 #topic Ocata sync 18:05:54 annak: np 18:06:10 #link https://review.openstack.org/#/q/topic:ocata_sync 18:06:30 annak: sorry to put you on the spot right away, hope you had a chance to catch you breath! 18:06:46 SumitNaiksatam: np :) 18:06:56 you posted a flurry of patches :-) 18:07:29 do you want to post a quick summary to update the team on what you are doing? 18:07:46 sure 18:08:50 i thought it would be helpful to estimate the ocata sync effort, and i tried to separate fixes that can be isolated from ocata (meaning - won't brake master) 18:09:13 these are the non-WIP ones 18:09:20 good idea 18:10:10 one has to do with removal of PLURALS from neutron. I feel like a bigger refactoring might be in place there, I think it the long run we are not supposed to import neutron directly 18:10:54 but I'm not sure if its a good time for big changes (and I don't understand the kitchen well enough yet..) 18:11:45 regadring the ocata sync patch - dependant repositories need to be updated as well and are currently blocking progress there 18:12:35 annak: yes, dont worry about the dependent repos, those will be take care off 18:12:58 *taken 18:14:04 to be fair to the patches which have already been posted, i thought we should try to get some of them merged first 18:14:13 before we process the ocata sync patches 18:15:00 does everyone agree? 18:15:16 SumitNaiksatam: sounds reasonable 18:15:26 but am fine either way 18:15:32 sorry the wifi is not stable :/ 18:15:55 i probably lost a couple of messages 18:16:04 annak: np, i was just asking - “to be fair to the patches which have already been posted, i thought we should try to get some of them merged first, before we process the ocata sync patches, does everyone agree?” 18:16:18 annak: what we discussed over emails 18:16:19 is there any reason to delay the smaller patches, and should these get back-ported to stable/newton as well? 18:16:55 rkukura: i am afraid we havent had enough reviews 18:17:22 since most of us dealing with the ipv6 stuff and some of the other aim driver related stuff 18:17:23 I think keeping master and stable/newton in sync as long as possible is helpful 18:17:33 rkukura: yeah 18:17:54 regarding backport, i think annak_ would know 18:18:34 if these don’t break master right now, I’d think they wouldn’t break stable/newton either, since master is based on Neutron stable/newton 18:19:20 no, they shouldn't break newton, since these are based on same libs 18:19:50 rkukura: annak_: makes sense 18:20:50 so i'll backport them once they get approved on master 18:22:06 annak_: okay 18:22:13 thanks 18:22:28 annak_: i havent had a chance to look into the patches in detail 18:22:35 so i dont have any questions right now 18:22:46 ok, np 18:22:53 anyone anyone else have questions? 18:23:21 annak_: thanks so much for taking this on! 18:23:42 SumitNaiksatam: np :) 18:23:53 our favorite topic 18:23:57 :) 18:24:05 #topic IP v4, v6 dual-stack support 18:24:26 #link https://review.openstack.org/458583 18:24:39 thats the spec 18:24:51 #link https://review.openstack.org/#/c/459823/ 18:24:58 * tbachman just pushed his update 18:25:08 I believe I’ve addressed the most recent feedback 18:25:14 tbachman: thanks for all the hard work on this 18:25:18 that said, it would be great if folks could have another look 18:25:20 SumitNaiksatam: np! 18:25:27 thanks to all those who’ve reviewed it! 18:25:36 tbachman: so you think the spec is pretty much done now? 18:25:40 it would be nice to get feedback from some of the services folks 18:25:51 (perhaps without the external segment changes) 18:25:55 SumitNaiksatam: ack 18:26:01 I still have to add that 18:26:04 tbachman: right, but dont see songole here 18:26:12 SumitNaiksatam: ack 18:26:36 The only other thing I could think of is that they might want to add an ip_version field 18:26:47 so that it would be included in the l3_policy creation 18:26:50 to support dual-stack 18:27:13 but at the moment, the changes shouldn’t break any of their stuff 18:27:49 tbachman: ah you mean, the services folks would need to set the ip_version appropriately from the NFP/NCP code 18:27:57 right 18:28:01 tbachman: got it 18:28:07 at the moment, it’s just using the default 18:28:10 and will continue to do so 18:28:19 they could add this to their config later if they wanted 18:28:25 and the workflow should be the same 18:28:48 (same as implicit L3P workflow) 18:29:09 yeah, was just saying going to say that, so for now the dual stack support is not available with NCP/NFP 18:29:10 * tbachman promises to use more specific words than “implicit” from now on :( 18:29:16 SumitNaiksatam: ack 18:29:43 tbachman: good thing to point out about the services’ integration 18:30:02 tbachman: the other question we had for you was the changes needed to the resource_mapping driver 18:30:09 ah, right 18:30:26 do you have a feel for what remains after your patch? 18:30:35 My thinking is that we should approve the spec, approve my current AIM patch, and then work on refactoring with the RMD 18:30:44 SumitNaiksatam: somewhat 18:31:01 tbachman: yeah 18:31:06 I think I could describe it from a high-level perspective 18:31:06 i agree with that plan 18:31:11 tbachman: sure 18:31:13 +1 18:31:17 go ahead 18:31:32 The RMD needs to move to using the subnetpools and address scopes 18:31:42 basically move a lot of the stuff out of the mapping driver and into the RMD 18:32:17 There are some AIM specific things that won’t go over though 18:32:23 like our mappings with VRFs etc. 18:32:29 some checks that won’t be needed 18:32:58 and if I remember correctly, there are some simplifications for the RMD (e.g. it can only be connected to a single ES, if my memory serves me well) 18:33:26 but certainly the AIM mapping code could be used to crib from 18:33:30 for the RMD changes 18:33:52 SumitNaiksatam: does that help? 18:34:02 tbachman: yes, thanks 18:34:22 tbachman: if i recall, the implementation for the subnet allocation from the subnetpool is already in the resource_mapping module 18:34:34 SumitNaiksatam: correct 18:34:35 however the resource_mapping driver is not making use of it 18:34:42 correct again 18:35:06 okay, thanks for confirming that, so that would be a matter of switching to using it, and testing 18:35:07 * tbachman notes that he stands on the shoulders of those who created the RMD code :) 18:35:21 I can try to take this task if it helps 18:35:29 :) 18:35:29 annak_: thanks, sure 18:35:50 annak_: a one-person coding army :) 18:35:52 annak_: thx! 18:35:53 annak_: so as we were discussing offline, this more of a matter of testing 18:36:36 is the current coverage good enough or do we need to add more? 18:36:56 annak_: i wasnt sure about that part, hence I had not done the switch until now :-) 18:37:02 annak_: there are UTs in the AIM driver that we’ll probably want to move to the RMD UTs 18:37:09 ok :) 18:37:11 tbachman: right 18:37:36 some of that may be a bit of work, as I doubt it will just drop in 18:37:43 annak_: as tbachman points out, when i did the subnetpool/address_scope stuff i put UTs in the aim_driver to test this 18:37:45 it might be best to leverage the infra from those UTs 18:37:59 (those being RMD, and not AIM) 18:38:00 ok, I'll start looking at all that 18:38:03 my plan was to move them over or replicate 18:38:13 but didnt get to it 18:39:30 annak_: thanks, and we can keep discussing this offline, so that you can make smooth progress 18:40:23 SumitNaiksatam: yes, that would help, thx 18:40:43 tbachman: anyhthinng to discuss on the implementation patch? 18:40:59 #link https://review.openstack.org/#/c/459823/ 18:41:13 SumitNaiksatam: not that I can think of. I’ve been able to do some functional validation, which is looking good, but I’d love to get more eyes on the patch 18:41:21 all feedback is welcome! 18:42:27 tbachman: one nit i had was that i was hoping to not have had to do that string to list conversion everywhere 18:42:39 SumitNaiksatam: ack 18:42:41 tbachman: but i am fine with what you have gotten working 18:42:55 the problem is that we need to check the prefixes 18:42:58 if its possible at all to do it in a different way, we can revisit later 18:43:04 so dealing with it as a list is easy 18:43:12 i know you have bigger issues to deal with right now 18:43:28 i think you already repsonded to my other comments 18:44:51 anhything else on this topic? 18:45:12 tbachman: thanks again for working on tis 18:45:19 SumitNaiksatam: thanks for the feedback! 18:45:19 #topic Open Discussion 18:45:21 and help! 18:45:26 tbachman: np 18:45:43 rkukura: did you end up attending the boston summit? 18:46:02 annak_: i havent forgotten your vmware driver patch 18:46:09 Just for a couple hours - too busy :( 18:46:18 annak_: apologies for being behind on the reviews for that 18:46:26 SumitNaiksatam: its still WIP 18:46:29 rkukura: ah okay 18:46:52 annak_: sure, had looked at it a little bit earlier but see that you are making progress, so thats great 18:47:20 rkukura: any thoughts/comments for the team based on what you saw/heard? 18:47:34 SumitNaiksatam: the backend API is still to be finalized, so it will stay WIP for a while.. 18:48:20 I was at one Neutorn forum session, which was mostly about documentation of linuxbridge vs ovs configuration 18:48:54 annak_: okay 18:49:06 rkukura: okay 18:50:04 I watched a video related to GBP ideas but GBP didn't get mentioned.. 18:50:12 trying to find a link 18:50:18 annak_: oh thats funny :-) 18:50:28 i am really curious 18:51:12 https://www.openstack.org/videos/boston-2017/future-of-cloud-networking-and-policy-automation 18:51:29 annak_: thanks for sharing, will take a look 18:51:48 it was about a broader scope of solutions (not just openstack) but still similar ideas 18:52:12 annak_: right, sounds very related 18:52:28 alrighty, if nothing else, we can get a few minutes back 18:52:35 thanks all for joining 18:52:37 bye! 18:52:43 SumitNaiksatam: l8r! 18:52:43 bye! 18:52:47 #endmeeting