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