18:02:34 <SumitNaiksatam> #startmeeting networking_policy
18:02:35 <openstack> Meeting started Thu Jul 13 18:02:34 2017 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:38 <openstack> The meeting name has been set to 'networking_policy'
18:02:54 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#July_13th.2C_6th_2017
18:03:05 <tbachman> :)
18:03:06 <tbachman> sorry for being late
18:03:17 <SumitNaiksatam> tbachman: np
18:03:33 <SumitNaiksatam> #topic Proposal to add Anna K and Thomas B to core team
18:03:42 <tbachman> :)
18:03:48 <SumitNaiksatam> annak: tbachman: a warm welcome once again! :-)
18:03:57 * tbachman throws hat in the air
18:03:57 <annak> thanks again for the honor!
18:04:02 <tbachman> thanks to all!
18:04:21 <SumitNaiksatam> annak: equally an honor and pleasure to have you on the team
18:04:34 <SumitNaiksatam> tbachman: annak: thanks for agreeing to take on the responsibility
18:04:51 <SumitNaiksatam> #topic Ocata sync
18:04:52 <tbachman> SumitNaiksatam: thanks for bringing us aboard!
18:05:01 <SumitNaiksatam> tbachman: np
18:05:01 * tbachman ^5’s annak
18:05:07 <SumitNaiksatam> #link https://review.openstack.org/#/q/topic:ocata_sync
18:05:31 <annak> tbachman: :)
18:05:45 <SumitNaiksatam> so our main patches are merged
18:05:55 <tbachman> SumitNaiksatam: annak: thanks for that huge effort!
18:05:58 <SumitNaiksatam> i started posting the client, UI and heat patches
18:06:14 <SumitNaiksatam> yeah big thanks to annak on that
18:06:53 <SumitNaiksatam> i just posted a new revision on the client patch, and i have also posted a test patch in the GBP repo which points to the client patch (and will eventually also to the UI and heat patch)
18:07:12 <SumitNaiksatam> if the client patch works, we would need to merge that first
18:07:18 <SumitNaiksatam> since the other repos depend on clinet
18:07:23 <SumitNaiksatam> *client
18:07:33 <SumitNaiksatam> client changes were minor
18:07:41 <SumitNaiksatam> waiting for the devstack gate test result
18:08:13 <SumitNaiksatam> tbachman: at some point were you planning to look at getting rid of the dependency of some of the apic repos?
18:08:22 <tbachman> SumitNaiksatam: ack
18:08:26 <rkukura> SumitNaiksatam: Assuming that passes, any reason to hold off before merging the client patch?
18:08:29 <SumitNaiksatam> tbachman: okay thanks
18:09:07 <SumitNaiksatam> rkukura: i dont think so, but i myself need to validate, i will +1 the client patch, and that should serve as a indication that we are good to go
18:09:11 <SumitNaiksatam> rkukura: sound okay?
18:09:31 <rkukura> ok, I’ll give all an initial review ASAP
18:09:39 <SumitNaiksatam> rkukura: yes please, thanks
18:10:21 <SumitNaiksatam> tbachman: based on how we decide to proceed, some of the changes which i made in the sumit/* branches (in say the apicapi repo) may not be required at all
18:10:32 <SumitNaiksatam> tbachman: so we can remove the dependency and just delete that branch
18:10:37 <tbachman> k
18:10:49 <tbachman> I think we have a patch to move some of the agent stuff
18:11:03 <tbachman> and then there’s the topic name
18:11:11 <tbachman> but aside from that, I think that was it
18:11:15 <tbachman> hoepfully not too much
18:11:16 <SumitNaiksatam> tbachman: perfect, so you have it tracked :-)
18:11:26 <SumitNaiksatam> i was just typing that up
18:11:39 <tbachman> SumitNaiksatam: ack. More or less ;)
18:11:48 <SumitNaiksatam> tbachman: that my recollection as well
18:12:00 <SumitNaiksatam> tbachman: i know you are busy with the release effort
18:12:05 <tbachman> no worries
18:12:13 <tbachman> I think there was a question on the allowed-address-pairs stuff, too
18:12:15 <SumitNaiksatam> tbachman: so this is obviously less priority than that
18:12:45 <tbachman> SumitNaiksatam: ack
18:13:36 <SumitNaiksatam> tbachman: need to refresh my memory on that, but i believe it was a matter of moving a table schema definition or something like that
18:13:43 <tbachman> right
18:13:56 <SumitNaiksatam> okay anything else on ocata_sync?
18:14:12 <SumitNaiksatam> moving on
18:14:21 <SumitNaiksatam> #topic VMware NSX Policy Driver
18:14:28 <SumitNaiksatam> #link https://review.openstack.org/453925
18:14:49 <SumitNaiksatam> i went through the patch
18:14:50 <annak> SumitNaiksatam: thanks for your comments, I'm working on them
18:14:58 <SumitNaiksatam> annak: np
18:15:03 <SumitNaiksatam> i am not familiar with the backend
18:15:08 <SumitNaiksatam> so i cant validate that part
18:15:33 <annak> yes, of course
18:15:51 <SumitNaiksatam> but i had some questions based on the configuration and because of that i was having a hard time try to reconcile with how this works
18:16:06 <SumitNaiksatam> but its quite possible i am misunderstanding the test configuration
18:16:13 <SumitNaiksatam> other than that the patch looked good to me
18:16:34 <SumitNaiksatam> if annak can valiate that it works, i am good to move forward
18:16:41 <SumitNaiksatam> rkukura: tbachman: any thoughts?
18:16:57 <SumitNaiksatam> i know you guys also looked at it at different times
18:17:00 <tbachman> SumitNaiksatam: I gave some initial comments (just nits). I’ll have a look at the recently-updated patch set
18:17:06 <SumitNaiksatam> tbachman: sure
18:17:14 <SumitNaiksatam> and i assume this is going to evolve over time
18:17:17 <rkukura> I have not given it a detailed review yet, but will today
18:17:25 <SumitNaiksatam> rkukura: thanks
18:17:53 <SumitNaiksatam> if annak is comfortable, hopefully we can merge this by the end of the week?
18:18:11 <SumitNaiksatam> (assuming review comments are provided and addressed)
18:18:15 <annak> regarding devstack - some config is missing indeed, and its a good idea to spawn all possible config from gbp side (such as core plugin)
18:18:35 <SumitNaiksatam> annak: yeah
18:18:43 <annak> SumitNaiksatam: yes, once the config side is done
18:18:46 <SumitNaiksatam> annak: you also mentioned you would be setting up a gate job
18:19:07 <SumitNaiksatam> annak: it of course will be a follow up
18:19:34 <SumitNaiksatam> but the devstack configuration would be helpful there
18:19:43 <annak> SumitNaiksatam: yes, but it will take some time - maybe a couple of weeks. the backend is still in development and some of the infra is missing
18:20:01 <SumitNaiksatam> annak: yes absolutely understandable
18:20:39 <SumitNaiksatam> annak: if you dont mind could you summarize in a few sentences as to how using the policy dirver here would be different from say, using NSX core plugin with the Neutron API?
18:20:57 <SumitNaiksatam> hopefully that would set a good context for the reviewers
18:22:59 <SumitNaiksatam> annak: still there?
18:23:02 <annak> SumitNaiksatam: assuming I understood the q correctly: the new driver configures all security stuff directly on the policy manager, bypassing neutron security groups, which is more effective
18:23:15 <SumitNaiksatam> annak: okay
18:23:49 <annak> nsx manager and policy manager are two different endpoints, and policy manager in turn configures the nsx manager
18:24:06 <SumitNaiksatam> annak: ah okay, that is good to know
18:24:19 <annak> nsx core plugin works against nsx manager
18:24:45 <SumitNaiksatam> okay, good to know
18:25:00 <annak> policy manager is a new solution that is intent-based, same idea basically as GBP
18:25:14 <SumitNaiksatam> annak: okay
18:25:37 <tbachman> intent is the new policy ;)
18:25:44 <SumitNaiksatam> annak: perhaps in the devref you can add a pointer to any public document that may be available on this
18:26:12 <SumitNaiksatam> annak: that will help anyone who wants to use this to understand readliy as to what componets are at play
18:26:13 <annak> but at current stage only the grouping objects and security maps between them is supported, so I inherited the connectivity part from resource mapping driver
18:26:20 <annak> SumitNaiksatam: yes, will do
18:26:33 <SumitNaiksatam> annak: sure, you have mentioned that in the patch, makes sense
18:26:44 <SumitNaiksatam> rkukura: tbachman do you have any more questions for annak on this?
18:26:50 <tbachman> SumitNaiksatam: not at this moment
18:26:58 <tbachman> will put any q’s I have in the gerrit
18:26:59 <rkukura> SumitNaiksatam, annak: that was very helpful
18:27:10 <tbachman> rkukura: ack on that
18:27:15 <SumitNaiksatam> tbachman: sure
18:27:21 <rkukura> no immediate questions from me
18:27:25 <SumitNaiksatam> rkukura: thanks
18:27:28 <SumitNaiksatam> moving on
18:27:41 <SumitNaiksatam> #topic Subnetpools in resource_mapping driver
18:27:52 <SumitNaiksatam> #link https://review.openstack.org/469681
18:28:20 <SumitNaiksatam> sorry, i dont have any new input on this yet, didnt spend any more time after the last discussion
18:28:27 <tbachman> SumitNaiksatam: same
18:28:42 <SumitNaiksatam> perhaps we can get back to this after the NSX driver is merged and the ocata_sync is completed
18:29:08 <SumitNaiksatam> rkukura: i believe you have been thinking about this in the background (in the context of the migration effortZ)
18:29:08 <annak> ok
18:29:14 <SumitNaiksatam> *effort
18:29:17 <rkukura> I started looking at thge patch again
18:29:51 <SumitNaiksatam> rkukura: okay
18:30:01 <rkukura> can someone remind me what the main issue was that seemed difficult to resolve, or am I totally confused?
18:30:37 <annak> rkukura: inability to configure subnets on same network from different address scope
18:31:03 <SumitNaiksatam> annak: nicely summarized
18:31:04 <tbachman> annak: even worse, different subnetpools
18:31:11 <SumitNaiksatam> tbachman: ack
18:31:24 <annak> sorry, different subnetpools :)
18:31:35 <SumitNaiksatam> and we need to do that since we were have to deal with the proxy_ip_pool (which is currently a separate pool from the l3p)
18:31:56 <rkukura> thanks. And whats the scenario where this would happen, given all subnets in an L2P should use the L3P’s subnetpool?
18:32:06 <SumitNaiksatam> rkukura: ^^^
18:32:13 <rkukura> right
18:32:19 <rkukura> its all coming back now
18:32:40 <SumitNaiksatam> annak: just to fill you in on the context of “migration”
18:32:49 <SumitNaiksatam> since we might reference this
18:33:12 <SumitNaiksatam> we are trying to figure out a way to migrate the old apic driver to the new one (aim_mapping)
18:33:37 <annak> ok
18:33:47 <SumitNaiksatam> the migration requires preserving the entire GBP/Neutron model
18:33:59 <SumitNaiksatam> and just adjusting the mapping
18:34:41 <SumitNaiksatam> but in a similar vein, we might even need to think about migrating older GBP users (prior to the use of subnetpools and address-scopes)
18:35:01 <SumitNaiksatam> to now, where every subnet will always have a subnetpool associated
18:35:02 <annak> yes, makes sense
18:35:43 <SumitNaiksatam> rkukura has been mostly leading the discussion on this
18:36:00 <SumitNaiksatam> but i thought it will be good to share the context here
18:36:09 <SumitNaiksatam> rkukura: anything you want to add?
18:36:22 <annak> SumitNaiksatam: thanks for the context!
18:36:32 <SumitNaiksatam> annak: you might see some patches around this, so hopefully you wont be surprised :-)
18:36:49 <rkukura> I’m hoping we can build a set of tools to handle the AIM plugin migration, and that one of these that takes care of the addition of subnetpools and address scopes might be usable for other PDs as well
18:37:04 <SumitNaiksatam> rkukura: nice
18:37:28 <rkukura> I do have a shorter term question on this
18:38:29 <rkukura> many projects (nova, neutron, …) try to support deployments that are based directly off the git repos, without any commit breaking anything for running deployments
18:39:08 <SumitNaiksatam> rkukura: you mean stable branches or trunk-chasers?
18:39:11 <rkukura> if we merge the switch to using pools and scopes, without a migration solution, we obviously wouldn’t be supporting these sorts of users
18:39:26 <rkukura> trunk-chasers is the term I was trtying to recall
18:39:47 <SumitNaiksatam> but i guess in GBP context my question is not as relevant
18:39:54 <SumitNaiksatam> since we aggressively backport
18:40:02 <rkukura> is it safe to assume GBP has no trunk-chasers? I don’t think we’ve worried too much about this in the past, but want to bring it up since the project has evolved
18:40:25 <SumitNaiksatam> rkukura: good question, i could have said with confidence in the past
18:40:35 <rkukura> I guess there could be stable branch trunk chasers too
18:40:46 <SumitNaiksatam> rkukura: yeah, and which is the case
18:41:36 <SumitNaiksatam> well let me backtrack slightly
18:41:55 <SumitNaiksatam> i am not aware of anyone building their own GBP packages, and deploying them
18:42:16 <rkukura> my view is we shoiuld not delay merging the subnetpool patch to our master, but just want to make sure
18:42:23 <SumitNaiksatam> there are obviously people deploying from packages that are build from the stable branches
18:42:46 <SumitNaiksatam> i dont know of anyone using a packages that is built from the master
18:43:02 <SumitNaiksatam> we support devstack like deployments for the master
18:43:21 <SumitNaiksatam> but we dont support and recommend deploying anything production from the master
18:44:29 <SumitNaiksatam> rkukura: i imagine i am just restating/reinforcing your assumptions?
18:44:52 <rkukura> I noticed there is a use_subnetpools config item in the patch. If setting this to false keeps the old behavior, maybe we should default it to false initially
18:45:13 <SumitNaiksatam> rkukura: okay, makes sense to me
18:46:04 <annak> rkukura: i think its only in resource_mapping patch, not in the aim patch?
18:46:04 <SumitNaiksatam> i dont think songole is here
18:46:35 <SumitNaiksatam> so we can skip the next agenda topic on NFP (i am looking at those patches)
18:47:08 <rkukura> annak: I don’t believe its configurable in AIM, and would prefer not to keep supporting the old way any longer than necessary
18:47:53 <annak> rkukura: ok, I can change the default
18:47:57 <SumitNaiksatam> rkukura: yeah, to the best of my recollection, aim_mapping will always use subnetpools
18:48:53 <rkukura> It would be ideal if new deployments defaulted to True, but upgrading an existing deployment to a new commit would default to False - maybe we should code the default as False and have devstack set it to True?
18:49:49 <annak> rkukura: ok (assuming there are any existing deployments..)
18:50:06 <SumitNaiksatam> annak: good point :-)
18:50:40 <rkukura> annak: maybe we don’t need to worry about trunk-chasers
18:50:41 <SumitNaiksatam> there are, but rkukura’s earlier comment regarding migrating the apic drivers will take care of those deployments
18:51:23 <rkukura> so maybe we keep this configurable until we have a migration tool, then phase out support for non-subnetpool usage
18:51:34 <annak> i meant deployments that depend on resource_mapping
18:52:25 <SumitNaiksatam> annak: right, i am not aware of but we might need to check with nfp because they were supporting some folks using resource_mapping driver earlier
18:52:46 <rkukura> ok, lets move this discussion to the review
18:53:08 <SumitNaiksatam> rkukura: ack
18:53:16 <SumitNaiksatam> anything else for today?
18:53:16 <annak> ok
18:53:36 <rkukura> not from me
18:53:43 <annak> is anyone planning to go to PTG/Sydney?
18:53:51 <tbachman> :)
18:54:01 * tbachman would love a free trip to Australia :)
18:54:19 <SumitNaiksatam> tbachman: +1
18:54:30 <rkukura> lets all go
18:54:32 <SumitNaiksatam> annak: not planning, too far! :-(
18:54:43 <SumitNaiksatam> rkukura: i like the spirit
18:54:54 <SumitNaiksatam> annak: you planning to go?
18:55:11 <annak> I'm thinking whether I should ask :)
18:56:01 <SumitNaiksatam> annak: yes its good to think before you ask, but you might get what you want :-)
18:56:44 <SumitNaiksatam> so anyone going to Sydney, please update the team
18:56:49 <annak> SumitNaiksatam: :)
18:56:55 <SumitNaiksatam> will be nice for the others to know
18:57:10 <SumitNaiksatam> may be those on the fence will change their minds :-)
18:57:13 <SumitNaiksatam> alrighty thanks all
18:57:17 <SumitNaiksatam> see you next week
18:57:19 <tbachman> SumitNaiksatam: thanks!
18:57:23 <rkukura> thanks SumitNaiksatam!
18:57:25 <annak> thanks, bye!
18:57:27 <SumitNaiksatam> #endmeeting