18:07:03 <SumitNaiksatam> #startmeeting networking_policy
18:07:04 <openstack> Meeting started Thu Sep 24 18:07:03 2015 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:07:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:07:08 <openstack> The meeting name has been set to 'networking_policy'
18:07:15 <ivar-lazzaro> lol
18:07:18 <SumitNaiksatam> and i was wondering why mageshgv was not visible
18:07:21 <SumitNaiksatam> my bad!
18:07:27 <rkukura> guess I’m not late after all ;)
18:07:36 <SumitNaiksatam> rkukura: lol
18:07:39 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Sept_3rd.2C_10th.2C_17th.2C_24th_2015
18:07:51 <SumitNaiksatam> #topic Integration tests and job
18:08:01 <SumitNaiksatam> i updated this patch #link https://review.openstack.org/222048
18:08:11 <SumitNaiksatam> which adds gbpfunc
18:08:24 <SumitNaiksatam> and ivar-lazzaro said “gotta look at that"
18:08:36 <SumitNaiksatam> other than that i dont have any other updates on gate jobs
18:08:44 <SumitNaiksatam> : #topic Packaging
18:08:48 <SumitNaiksatam> #topic Packaging
18:09:04 <SumitNaiksatam> rkukura: any updates at your end (i have one)
18:09:07 <SumitNaiksatam> ?
18:09:43 <rkukura> My only update is that our stuff will be removed from fedora 23 soon if we don’t update the dependencies
18:09:59 <SumitNaiksatam> okay
18:10:07 <SumitNaiksatam> and update from what to what?
18:10:14 <rkukura> I should be able to take care of this by next week’s meeting, along with updating to our newest releases
18:10:31 <rkukura> the issue is broken dependencies that prevent the packages from building
18:10:56 <rkukura> Assuming the rest of OpenStack is still in F23, I’ll udpate GBP.
18:11:10 <SumitNaiksatam> rkukura: ok, so this is across juno and kilo?
18:11:14 <rkukura> I think there is a plan to no longer include OpenStack services in Fedora
18:11:36 <rkukura> I need to check which OpenStack release F23 includes (if any)
18:11:52 <rkukura> The OpenStack clients will still be in Fedora
18:11:56 <SumitNaiksatam> rkukura: ok
18:12:08 <rkukura> But RDO will be preferred for deploying the services on Fedora
18:12:11 <SumitNaiksatam> rkukura: would you need a new stable release of juno and kilo for this?
18:12:33 <SumitNaiksatam> rkukura: we havent released one for a while now, but we have made several updates since the last one release
18:12:41 <rkukura> I’d use the latest stable release of whichever it includes
18:12:48 <SumitNaiksatam> rkukura: okay
18:12:54 <rkukura> Probably makes sense to release new stable versions then
18:13:03 <SumitNaiksatam> rkukura: yes, sure will do
18:13:09 <rkukura> SumitNaiksatam: What is your update?
18:13:13 <SumitNaiksatam> rkukura: yeah
18:13:27 <SumitNaiksatam> so i updated the juno client
18:13:45 <SumitNaiksatam> and it no longer depends on the 2.3.9 version of neutron client
18:14:05 <SumitNaiksatam> it now aligns with 2.3.12 which is also the same version as in the global requirements
18:14:23 <rkukura> Sounds good
18:14:28 <SumitNaiksatam> which means that this aligns well with the oslo libraries that the rest of openstack is using
18:14:33 <SumitNaiksatam> rkukura: okay
18:15:03 <SumitNaiksatam> we need to see if this is going to have any impact on existing deployments
18:15:32 <SumitNaiksatam> mageshgv: i dont think this impacts you since your users are using kilo client
18:15:49 <mageshgv> SumitNaiksatam: right
18:16:08 <SumitNaiksatam> for any other deployment this should hopefully just result in automatically updating the neutronclient version as well
18:16:14 <SumitNaiksatam> but i havent tested
18:16:29 <SumitNaiksatam> i only tested on devstack
18:16:41 <SumitNaiksatam> rkukura:  that was my update
18:16:51 <rkukura> SumitNaiksatam: thanks!
18:17:03 <SumitNaiksatam> rkukura: in case you were setting the neutronclient dependency explicitly somewhere then may be you can check
18:17:31 <rkukura> Yes, I’ll update that as part of updating the packages.
18:17:46 <SumitNaiksatam> rkukura: great, thanks!
18:17:54 <SumitNaiksatam> #topic Bugs
18:18:22 <SumitNaiksatam> ivar-lazzaro: i believed jishnu confirmed that #link https://bugs.launchpad.net/group-based-policy/+bug/1486740 should be fixed now
18:18:24 <openstack> Launchpad bug 1486740 in Group Based Policy "GBP Ext-Seg: L3Policy cannot be updated to a new Ext-Seg" [High,Incomplete] - Assigned to Ivar Lazzaro (mmaleckk)
18:18:28 <SumitNaiksatam> *believe
18:18:53 <SumitNaiksatam> hopefully he will update LP, or i will do it later
18:18:55 <ivar-lazzaro> nice
18:19:09 <SumitNaiksatam> rkukura: regarding #link https://bugs.launchpad.net/group-based-policy/+bug/1462024
18:19:10 <openstack> Launchpad bug 1462024 in Group Based Policy "Concurrent create_policy_target_group call fails" [High,In progress] - Assigned to Robert Kukura (rkukura)
18:19:20 <SumitNaiksatam> #link https://review.openstack.org/224293
18:19:28 <SumitNaiksatam> i tried to follow up with ajay yesterday
18:19:43 <SumitNaiksatam> i am not quite sure i got the message across though
18:20:01 <rkukura> I’m convinced that using utils.clean_session() helps
18:20:10 <SumitNaiksatam> rkukura: nice
18:20:22 <SumitNaiksatam> rkukura: perhaps we can get into a short meeting with him to explain what we expect from him regarding the tests
18:20:35 <rkukura> So I need to decide whether to add functions to local_api that do this, or keep in in implicit_policy.
18:20:49 <rkukura> SumitNaiksatam: meeting with Ajay makes sense
18:20:54 <SumitNaiksatam> rkukura: okay
18:21:35 <rkukura> I think I will finish up my patch and cleanup the logging, but leave enough debug logging to be helpful for him.
18:21:45 <SumitNaiksatam> rkukura: sounds good
18:21:51 <SumitNaiksatam> rkukura: so which functions are missing?
18:21:59 <rkukura> In local_api?
18:22:26 <SumitNaiksatam> rkukura: you mentioned you needed to decide whether to add functions
18:22:48 <SumitNaiksatam> you mean the calls to clean_session()?
18:22:56 <rkukura> Yes, these would be wrappers for create_l3_policy and get_l3_policies that call clean_session.
18:23:30 <ivar-lazzaro> rkukura: using local_api is a good idea, we are putting SC constructs there as well anyways
18:23:42 <rkukura> OK, that’s what I’ll do
18:23:46 <SumitNaiksatam> ivar-lazzaro: i agree
18:23:56 <SumitNaiksatam> since all drivers can make use of it i guess
18:24:06 <rkukura> So I should have any updated patch later today that we can review and merge hopefully.
18:24:07 <SumitNaiksatam> although for now we always use implicit policy
18:24:28 <SumitNaiksatam> rkukura: okay, so you want to have the discussion with ajay before that?
18:24:40 <rkukura> Either way - what timezone is he?
18:24:47 <SumitNaiksatam> he is local here
18:24:54 <SumitNaiksatam> as you mentioned, it would be great to have a clean rally run
18:25:06 <SumitNaiksatam> clean meaning, 100% success
18:25:11 <rkukura> Agreed
18:25:36 <SumitNaiksatam> okay
18:26:11 <SumitNaiksatam> rkukura: any updates on #link https://bugs.launchpad.net/group-based-policy/+bug/1417312 or #link https://bugs.launchpad.net/group-based-policy/+bug/1470646 ?
18:26:13 <openstack> Launchpad bug 1417312 in Group Based Policy "GBP: Existing L3Policy results in failure to create PTG with default L2Policy" [High,Confirmed] - Assigned to Robert Kukura (rkukura)
18:26:14 <openstack> Launchpad bug 1470646 in Group Based Policy "Deleting network associated with L2P results in infinite loop" [High,Triaged] - Assigned to Robert Kukura (rkukura)
18:26:52 <rkukura> I haven’t done anything regarding the latter yet, and need to look at the first one again to see if its related to my current patch.
18:27:30 <SumitNaiksatam> rkukura: okay
18:27:38 <SumitNaiksatam> rkukura: thanks for the updates
18:28:09 <SumitNaiksatam> mageshgv: any updates on #link https://bugs.launchpad.net/group-based-policy/+bug/1489090 and #link https://bugs.launchpad.net/group-based-policy/+bug/1418839 ?
18:28:11 <openstack> Launchpad bug 1489090 in Group Based Policy "GBP: Resource intergrity fails between policy-rule-set & external-policy" [High,Confirmed] - Assigned to Magesh GV (magesh-gv)
18:28:12 <openstack> Launchpad bug 1418839 in Group Based Policy "Service config in yaml cannot be loaded" [High,In progress] - Assigned to Magesh GV (magesh-gv)
18:28:45 <mageshgv> SumitNaiksatam:  I did  not get time to work on it this week, will try to post a patch over the weekend
18:28:53 <rkukura> thanks ivar-lazzaro for pointing out the clean_session idea - that saved a ton of time
18:28:53 <SumitNaiksatam> mageshgv: thanks!
18:29:05 <SumitNaiksatam> rkukura: +1
18:29:16 <ivar-lazzaro> rkukura: I'm glad it helped!
18:29:52 <SumitNaiksatam> any other high priority bugs
18:30:57 <SumitNaiksatam> there are a few in the UI, but i dont think we have the right people here to discuss
18:31:10 <SumitNaiksatam> #topic Node Composition Plugin/Driver/Plumber enhancements
18:31:23 <SumitNaiksatam> #link https://review.openstack.org/#/c/203226/
18:31:50 <SumitNaiksatam> ivar-lazzaro: are there plans to update the above with references to the proxy ptg constructs?
18:32:07 <SumitNaiksatam> constructs -> extension
18:32:10 <ivar-lazzaro> SumitNaiksatam: mmmh I don't think it should be the same spec
18:32:20 <ivar-lazzaro> but I agree we need something
18:32:27 <SumitNaiksatam> ivar-lazzaro: okay
18:32:34 <ivar-lazzaro> I would keep that spec solely for updating our plumbing terminology
18:32:40 <SumitNaiksatam> yeah, it should be captured somewhere
18:32:44 <SumitNaiksatam> ivar-lazzaro: okay
18:33:06 <ivar-lazzaro> no need to mix up with plumber specific techniques, that's orthogonal
18:33:28 <SumitNaiksatam> i also want to discuss a little bit of process regarding documenting the design
18:33:45 <SumitNaiksatam> lets park it for now and come back to it in the open discussion topic
18:34:25 <SumitNaiksatam> so we have the following series which i believe is ready for review and being actively tested by #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master+topic:bp/node-centric-chain-plugin,n,z
18:34:53 <ivar-lazzaro> Have couple of tests failing
18:35:03 <ivar-lazzaro> but will fix right after this meeting
18:35:05 <SumitNaiksatam> ivar-lazzaro: yeah, noticed that yesterday
18:35:08 <SumitNaiksatam> ivar-lazzaro: thanks
18:35:48 <SumitNaiksatam> mageshgv: i believe you had discussion with ivar-lazzaro to fix the pending issues in this patch #link https://review.openstack.org/166424 as  follow up?
18:36:20 <mageshgv> SumitNaiksatam: yes, we were discussing a few issues about the node and spec ownership
18:36:34 <mageshgv> We can address them as a follow up patch
18:37:03 <igordcard__> hi, does the new ncp work with odl as backend as well?
18:37:44 <ivar-lazzaro> igordcard__: ncp in general should be orthogonal, it really depends on the plumber
18:37:47 <SumitNaiksatam> igordcard__: ah good to see you here :-)
18:38:10 <ivar-lazzaro> igordcard__: if we plan on using the Traffic Stitching Plumber, then we need the ODL folks to add support for proxy groups in their driver
18:38:46 <ivar-lazzaro> that should be already enough, the design is made so that supporting the proxy group extension will make you automatically compliant with the TScP
18:39:19 <ivar-lazzaro> nonetheless, we don't have a spec for the proxy group extension yet... But I promise I'll work on it :)
18:39:36 <igordcard__> I haven't yet been able to meet the proxy group, but will check it out
18:40:20 <SumitNaiksatam> ivar-lazzaro: yeah, that was my feeling too, we need to have the proxy design documented
18:40:32 <SumitNaiksatam> ivar-lazzaro: that would have helped with more people getting involved with the review as well
18:40:43 <ivar-lazzaro> yes
18:41:16 <ivar-lazzaro> I also had one more change that I wanted to make (after we merge this series) and I'd like the team opinion about this
18:41:17 <SumitNaiksatam> ivar-lazzaro: that said, its fantastic work!
18:41:28 <ivar-lazzaro> (especially rkukura since it's related to the ML2 design)
18:41:35 <SumitNaiksatam> ivar-lazzaro: please go ahead
18:42:02 <ivar-lazzaro> I was thinking about splitting up our RMD and the SC mapping logic
18:42:15 <ivar-lazzaro> (because... you know... many many lines of code)
18:42:34 <ivar-lazzaro> and I was thinking of doing so by creating a new driver called chain_mapping
18:42:57 <ivar-lazzaro> with the only purpose of defining what the SC workflow should look like for GBP
18:43:00 <SumitNaiksatam> ivar-lazzaro: so just to be clear, this is a policy driver
18:43:07 <ivar-lazzaro> SumitNaiksatam: yes
18:43:07 <SumitNaiksatam> ivar-lazzaro: and not a service chain driver
18:43:20 <ivar-lazzaro> yeah that would run together with IPD and RMD
18:43:25 <SumitNaiksatam> ivar-lazzaro: right
18:43:32 <ivar-lazzaro> it would be the last of the chain (pun intended)
18:43:40 <SumitNaiksatam> ivar-lazzaro: lol
18:44:05 <ivar-lazzaro> the advantage of doing so, besides obvious reusability
18:44:17 <ivar-lazzaro> id that we can finally converge on ONE WAY of doing SC
18:44:25 <ivar-lazzaro> without all the drivers trying to do that on their own
18:44:46 <ivar-lazzaro> (for instance, provider centric chains were just adopted by the APIC mapping at first)
18:45:23 <ivar-lazzaro> and with a smaller amount of code to work on, it'll be easier to review and make design decisions
18:45:30 <SumitNaiksatam> ivar-lazzaro: all drivers inherit from RMD, so it doesnt increase reusability per say, right?
18:45:37 <ivar-lazzaro> I'll be more self documenting than before
18:45:54 <SumitNaiksatam> ivar-lazzaro: chain_mapping would require RMD to run right?
18:45:55 <ivar-lazzaro> SumitNaiksatam: they do, but sometimes they have to change the neutron mapping
18:46:12 <ivar-lazzaro> SumitNaiksatam: and when they do, they need to rewrite a method almost entirely
18:46:25 <ivar-lazzaro> even the SC parts
18:46:32 <SumitNaiksatam> ivar-lazzaro: okay, i am definitely in favor of better modularity
18:46:40 <ivar-lazzaro> SumitNaiksatam: no! in theory, that can perfectly work by itself
18:46:59 <SumitNaiksatam> ivar-lazzaro: what is it in practice?
18:47:28 <ivar-lazzaro> SumitNaiksatam: in practice I'm not sure what would happen to datapath if you did that... that's only a bunch of entry in the database
18:47:37 <ivar-lazzaro> SumitNaiksatam: but the database would look just fine
18:47:41 <SumitNaiksatam> ivar-lazzaro: okay
18:48:06 <SumitNaiksatam> ivar-lazzaro: in theory we should have been able to use RMD withouth IPD, but i think we realized that it doesnt work that way ;-)
18:48:18 <ivar-lazzaro> SumitNaiksatam: so people can write their own mapping drivers without worrying about SC... As long as they can support proxy_group extension for the plumber
18:48:18 <SumitNaiksatam> ivar-lazzaro: anyway orthogonal discussion, sorry for distracting
18:48:29 <SumitNaiksatam> ivar-lazzaro: right, makes sense
18:48:44 <ivar-lazzaro> SumitNaiksatam: yeah that's very true :)
18:49:00 <SumitNaiksatam> ivar-lazzaro: perhaps a concrete example of what gets factored out might help everyone to understand better
18:49:14 <ivar-lazzaro> SumitNaiksatam: I'm actually already working on a patch
18:49:20 <SumitNaiksatam> ivar-lazzaro: so may be a very small patch will also be very helpful
18:49:28 <SumitNaiksatam> ivar-lazzaro: awesome, guessed as much! ;-)
18:49:29 <ivar-lazzaro> SumitNaiksatam: actually, it's already done
18:49:36 <ivar-lazzaro> SumitNaiksatam: but UTs are still failing
18:49:42 <SumitNaiksatam> ivar-lazzaro: okay np
18:50:00 <SumitNaiksatam> mageshgv: what is your opinion about this?
18:50:08 <SumitNaiksatam> in case you got a chance to think through
18:50:12 <ivar-lazzaro> I've designed that to be on top of the existing chain... Which is a terrible maintenance choice... but it's easier to pull it off
18:50:42 <ivar-lazzaro> rkukura: is there any particular implication I should be more aware of? except for taking into account deleting order?
18:50:49 <mageshgv> SumitNaiksatam: I had an offline discussion with ivar-lazzaro on this, I am +1 for this, it really helps in maintaining and modularization and code reuse
18:51:08 <SumitNaiksatam> mageshgv: awesome!
18:51:57 <rkukura> ivar-lazzaro: All sounds good in theory, but I’m not clear on how much coupling there is between your SC driver and the other policy drivers.
18:52:29 <ivar-lazzaro> rkukura: you mean the SC plugin?
18:52:49 <ivar-lazzaro> today, the SC plugin (and its drivers) can only create GBP resource
18:53:00 <ivar-lazzaro> they *never* talk to Neutron directly (by design)
18:53:10 <rkukura> ivar-lazzaro: I meant the chain_mapping policy driver
18:53:28 <ivar-lazzaro> That should be able to even run alone
18:53:46 <ivar-lazzaro> the semantic is very simple: find a redirect, create a chain
18:54:04 <ivar-lazzaro> never using external Openstack modules (except for Keystone for admin owned chains)
18:54:34 <ivar-lazzaro> it does almost no validation, except for things like "only one redirect per PRS
18:54:56 <ivar-lazzaro> and it doesn't even depend on proxy_group
18:55:31 <ivar-lazzaro> that said, I might have missed something... but coupling seems nill
18:55:53 <SumitNaiksatam> ivar-lazzaro: okay, i think looking at the patch will probabyl making this much more clear
18:55:57 <rkukura> ivar-lazzaro: What you are describing sounds fine - but you seem to be a bit concerned
18:57:21 <ivar-lazzaro> rkukura: not really, so far it's looking good... I just wanna make sure I'm not overlooking some fundamental ML2ish design constraint
18:57:28 <rkukura> ivar-lazzaro: Are you doing everything that creates resources during postcommit?
18:57:44 <ivar-lazzaro> yup
18:57:57 <ivar-lazzaro> as SumitNaiksatam said, maybe with a patch we can discuss better
18:58:07 <ivar-lazzaro> I'll post one once I fix the UTs
18:58:09 <rkukura> Right, but sounds good so far.
18:58:39 <SumitNaiksatam> ivar-lazzaro:thanks for bringing it up
18:59:27 <SumitNaiksatam> ivar-lazzaro: mageshgv: so to summarize - we are going forward with #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master+topic:bp/node-centric-chain-plugin,n,z
18:59:39 <SumitNaiksatam> after the UTs are fixed
18:59:52 <SumitNaiksatam> and the gate job reports succes on the integration tests
18:59:56 <mageshgv> SumitNaiksatam: sounds good
19:00:13 <SumitNaiksatam> mageshgv: you are comfortable will all patches in the series?
19:00:34 <SumitNaiksatam> ivar-lazzaro: i believe you will need to remove WIP wherever applicable
19:00:47 <ivar-lazzaro> yeah
19:00:52 <SumitNaiksatam> okay we have hit the hour
19:01:00 <mageshgv> SumitNaiksatam:  I am fine with the patches, will go over them once more to make sure I didnt miss anything
19:01:09 <SumitNaiksatam> mageshgv: ivar-lazzaro: great
19:01:16 <SumitNaiksatam> i wanted to bring up some discussion regarding documenting design and API
19:01:20 <SumitNaiksatam> but we are out of time
19:01:25 <SumitNaiksatam> i will try to communicate offline
19:01:28 <SumitNaiksatam> thanks all for joining
19:01:32 <SumitNaiksatam> bye!
19:01:33 <mageshgv> bye
19:02:01 <SumitNaiksatam> #endmeeting