18:02:53 <SumitNaiksatam> #startmeeting networking_policy
18:02:54 <openstack> Meeting started Thu Sep 10 18:02:53 2015 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:57 <rkukura> hi again
18:02:58 <openstack> The meeting name has been set to 'networking_policy'
18:03:22 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Sept_3rd.2C_10th_2015
18:03:54 <SumitNaiksatam> let’s change the order of topics a little and tackle the shorter items first
18:04:01 <SumitNaiksatam> #topic Integration tests
18:04:48 <SumitNaiksatam> ransari: hi
18:04:58 <ransari> Hi
18:05:17 <SumitNaiksatam> so per discussion earlier, i have posted this patch which moves the gbpfunctests into the tree #link https://review.openstack.org/#/c/222048/2
18:05:59 <SumitNaiksatam> since this is kind of an “external” test suite by Jishnu, we have added it to the contrib directory
18:06:12 <SumitNaiksatam> so its not subject to pep8 and other checks
18:06:24 <SumitNaiksatam> but at least this way we have it in tree
18:06:30 <SumitNaiksatam> thoughts?
18:06:52 <rkukura> makes sense to me
18:06:59 <SumitNaiksatam> this will allow us to update the integration tests along with the changes that we introduce with the patches
18:07:02 <SumitNaiksatam> rkukura: okay
18:07:11 <SumitNaiksatam> ivar-lazzaro: thanks for the review
18:07:16 <SumitNaiksatam> i have updated the README
18:07:25 <ivar-lazzaro> SumitNaiksatam: nice
18:07:35 <SumitNaiksatam> ivar-lazzaro: i think you asked about multinode?
18:07:58 <ivar-lazzaro> more generally, how you define the testbed
18:08:06 <SumitNaiksatam> ivar-lazzaro: that is an artifact of the devstack job itself
18:08:10 <SumitNaiksatam> this is single node
18:08:34 <SumitNaiksatam> i am not sure that there are any other multi-node jobs that are supported
18:08:48 <SumitNaiksatam> but i am happy to be corrected
18:09:11 <ivar-lazzaro> what if I already have an openstack installation somewhere? Can I run the suite against it?
18:09:24 <ivar-lazzaro> just like tempest can?
18:09:34 <SumitNaiksatam> ivar-lazzaro: yes
18:09:57 <SumitNaiksatam> ivar-lazzaro: the test suite basically makes CLI calls
18:10:13 <SumitNaiksatam> and does not assume anything about how the infra is deployed
18:10:19 <ivar-lazzaro> ok, so I just need to install the suite in the controller
18:10:26 <SumitNaiksatam> it also does not configure anything
18:10:29 <SumitNaiksatam> ivar-lazzaro: yes
18:10:32 <ivar-lazzaro> or configure CLI properly
18:10:38 <ivar-lazzaro> ok
18:11:36 <SumitNaiksatam> so hopefully we can get this merged in after it passes the gate
18:11:49 <ivar-lazzaro> cool! When I get some time I'll try do PEP8ize the suite, good excuse to go through the code more carefully
18:12:00 <SumitNaiksatam> ivar-lazzaro: great, thanks! ;-)
18:12:20 <SumitNaiksatam> regarding the rally job
18:13:01 <SumitNaiksatam> it is now possible to get a failed job status if any of the tests is not successful 100% of the time
18:13:08 <SumitNaiksatam> Yi: hi
18:13:30 <SumitNaiksatam> however, i have hesitated to instrument this in our job
18:14:19 <SumitNaiksatam> since we have some pending issues in the existing code
18:14:54 <SumitNaiksatam> we need to figure out a way on how we can transition to make use of the rally test feedback to avoid new issues creeping while fix the existing ones
18:15:04 <SumitNaiksatam> *while we
18:15:44 <SumitNaiksatam> i believe most of the time we are hitting the create PTG issue that rkukura is investigating and we will get to in a bit
18:15:59 <rkukura> I hope to have a fix for that one very soon
18:16:07 <SumitNaiksatam> so may be if we figure out a solution for that, we can transition to gating on the rally job as well
18:16:10 <SumitNaiksatam> rkukura: great!
18:16:17 <SumitNaiksatam> #topic Packaging
18:16:32 <SumitNaiksatam> rkukura: anything to update?
18:17:21 <rkukura> Nothing new on packaging from me. I’m planning to look into RDO’s delorean automated package build system as soon as I get a chance.
18:18:17 <rkukura> And get RDO (and Fedora if still relevant) packages available for stable/juno and kilo in the next couple weeks.
18:18:31 <SumitNaiksatam> rkukura: okay thanks
18:18:38 <SumitNaiksatam> #topic Bugs
18:19:20 <SumitNaiksatam> list go through the list of prioritized bugs
18:19:24 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1488652
18:19:25 <openstack> Launchpad bug 1488652 in Group Based Policy "Implicit L3Policy Creation fails when multiple subnet are configured for an external network" [High,Confirmed] - Assigned to Ivar Lazzaro (mmaleckk)
18:20:10 <SumitNaiksatam> ivar-lazzaro: thanks for the posting the patch #link https://review.openstack.org/#/c/221898/
18:20:38 <ivar-lazzaro> that's ready for review!
18:20:42 <SumitNaiksatam> ransari: this is supposed to address the bug you had raised
18:21:41 <SumitNaiksatam> ransari: it at least avoids the case where using floating IPs from teh external subnet pool exhausts the pool and no new l3ps can be associated with the external network
18:21:55 <SumitNaiksatam> ransari: will help if you can take a look at the patch
18:23:26 <SumitNaiksatam> ivar-lazzaro: any chance that you can update the commit message with some of the rationale (and high level workflow changes) that you were mentioning?
18:24:13 <ivar-lazzaro> sure
18:24:17 <SumitNaiksatam> ivar-lazzaro: thanks
18:24:36 <SumitNaiksatam> i believe mageshgv is validating #link https://review.openstack.org/179327
18:25:19 <SumitNaiksatam> ivar-lazzaro: not sure you got a chance to look at this: #link https://bugs.launchpad.net/group-based-policy/+bug/1486740
18:25:21 <mageshgv> SumitNaiksatam: Actually not me, but I believe ransari tried it our earlier
18:25:23 <openstack> Launchpad bug 1486740 in Group Based Policy "GBP Ext-Seg: L3Policy cannot be updated to a new Ext-Seg" [High,Confirmed] - Assigned to Ivar Lazzaro (mmaleckk)
18:25:34 <SumitNaiksatam> but it might probably be not that big
18:25:39 <SumitNaiksatam> mageshgv: ah ok
18:25:43 <SumitNaiksatam> ransari: thats great
18:26:06 <ivar-lazzaro> SumitNaiksatam: haven't looked at that yet
18:26:15 <SumitNaiksatam> rkukura: i believe you were also playing around with #link https://review.openstack.org/179327?
18:26:42 <rkukura> I had looked at it a while back
18:27:06 <rkukura> Looks like I gave it a +2 back then - can re-review
18:27:27 <rkukura> once its rebased
18:27:42 <SumitNaiksatam> oh thats the wrong lin
18:27:43 <SumitNaiksatam> link
18:27:59 <SumitNaiksatam> i meant #link https://review.openstack.org/166424
18:28:23 <rkukura> That makes more sense
18:28:51 <rkukura> I’m trying to get the nova driver to work with it, but still not successfully
18:28:59 <SumitNaiksatam> sorry about the confusion
18:29:12 <SumitNaiksatam> rkukura: okay
18:29:29 <rkukura> It may be my own confusion on how I had gotten the nova node driver to work before.
18:29:30 <SumitNaiksatam> rkukura: is it issues with ivar-lazzaro’ s patch or issues on the nova driver side?
18:29:37 <SumitNaiksatam> rkukura: okay
18:29:49 <SumitNaiksatam> mageshgv: so you are validating the above, right?
18:30:03 <rkukura> I think ivar-lazzaro’s patch is working as intended, I just don’t seem to be able to get the ‘service’ tenant credentials
18:30:11 <mageshgv> SumitNaiksatam: yes, I am on it since yesterday
18:30:27 <SumitNaiksatam> mageshgv: yes, we are eager to hear how its going? ;-)
18:30:41 <SumitNaiksatam> rkukura: okay
18:31:04 <mageshgv> The patch works fine, just a few minor issues, will send them out
18:31:15 * ivar-lazzaro brace himself for all the incoming issues and curses
18:31:21 <mageshgv> :-
18:31:31 <SumitNaiksatam> mageshgv: ivar-lazzaro :-)
18:31:56 <SumitNaiksatam> ivar-lazzaro: to me sounds like mageshgv is happy :-)
18:32:12 <mageshgv> SumitNaiksatam, ivar-lazzaro: Just tested one chain, create and delete :)
18:32:31 <SumitNaiksatam> mageshgv: nice
18:32:40 <SumitNaiksatam> mageshgv: which node driver are you using?
18:32:55 <SumitNaiksatam> base Heat or OC?
18:33:04 <mageshgv> SumitNaiksatam: I am using a custom node driver that our One Convergence team is developing
18:33:20 <SumitNaiksatam> mageshgv: okay, but thats kind of a superset of the Heat node driver?
18:33:54 <mageshgv> SumitNaiksatam: Kind of, but with a change in model that it uses Heat driver only for configuration and Nova for instantiation
18:34:16 <SumitNaiksatam> mageshgv: ok
18:34:43 <SumitNaiksatam> mageshgv: but the plumber aspects will apply to both drivers almost in an identical way i guess
18:35:11 <mageshgv> SumitNaiksatam: Actually the Heat driver does not use the plumber, but our One Convergence driver does
18:35:42 <SumitNaiksatam> mageshgv: okay, i will sync up after this
18:35:49 <mageshgv> SumitNaiksatam: okay
18:35:59 <ivar-lazzaro> mageshgv: are you using the traditional RMD or the APIC driver?
18:36:31 <mageshgv> ivar-lazzaro: Right now I am using APIC on the setup, but my UTs are against RMD :-
18:37:04 <SumitNaiksatam> ivar-lazzaro: mageshgv my understanding was that the plumber should be usable with the RMD and the Heat Node driver as is, right?
18:37:05 <mageshgv> ivar-lazzaro: So it should work with both unless the UTs do not cover some aspect
18:37:28 <ivar-lazzaro> mageshgv: well, datapath may be the issue there
18:37:54 <ivar-lazzaro> but now we have functional tests in tree! So we just need to run them against RMD :-)
18:38:05 <mageshgv> SumitNaiksatam: No, we will need enhancements to the heat node driver if it has to instantiate a VM as part of  the template
18:38:45 <SumitNaiksatam> mageshgv: i see, what you are saying is that the plumber is not relevant if we are not spinning up VMs
18:38:50 <mageshgv> ivar-lazzaro: Right, we can add data path tests as well in tree
18:38:58 <mageshgv> SumitNaiksatam: right
18:39:26 <mageshgv> ivar-lazzaro: although we need a lot more work for that :-
18:39:56 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1462024
18:39:57 <openstack> Launchpad bug 1462024 in Group Based Policy "Concurrent create_policy_target_group call fails" [High,Confirmed] - Assigned to Robert Kukura (rkukura)
18:40:07 <SumitNaiksatam> ivar-lazzaro: mageshgv: thanks
18:40:12 <SumitNaiksatam> rkukura: over to you
18:40:32 <SumitNaiksatam> rkukura: sounded like you had a better handle on the above?
18:40:44 <rkukura> I think there is a relatively straightforward fix for this, that will work as long as overlapping L3Ps per tenant are forbidden.
18:41:00 <SumitNaiksatam> rkukura: okay, i think we can certainly start with that
18:41:20 <ivar-lazzaro> rkukura: would it be terribly hard to move to a more generic solution once we allow that?
18:41:28 <rkukura> But if/when that restriction is relaxed, a somewhat more invoved fix will be needed to prevent multiple default L3Ps from getting created.
18:41:58 <rkukura> I think the simpler fix first makes sense, and will try to get that into review tomorrow.
18:42:51 <SumitNaiksatam> rkukura: i agree, i think we should first fix the feature (or constraints) we are supporting today
18:43:02 <rkukura> OK
18:43:31 <SumitNaiksatam> rkukura: any update on #link https://bugs.launchpad.net/group-based-policy/+bug/1417312 and #link https://bugs.launchpad.net/group-based-policy/+bug/1470646
18:43:33 <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:43:34 <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:43:54 <rkukura> No, I’ll investigate those later today.
18:44:10 <SumitNaiksatam> rkukura: okay
18:44:39 <SumitNaiksatam> mageshgv: over to you - 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:44:41 <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:44:42 <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:45:34 <mageshgv> Have to add validation to reject deletion of inuse External policy. Its a straight forward one, will post a fix soon
18:45:51 <mageshgv> The second one is something local to Heat node driver
18:46:10 <SumitNaiksatam> mageshgv: thanks
18:46:28 <SumitNaiksatam> any other major issues that have popped up and we did not cover?
18:46:57 <SumitNaiksatam> there are a few things in the UI which we really need to fix asap, but i dont think anyone working on the UI is here
18:47:12 <SumitNaiksatam> #topic Open Discussion
18:47:19 <SumitNaiksatam> i had one thing to bring up regarding the client
18:47:59 <SumitNaiksatam> our juno CLI/client (used to be 0.9.1) was dependent on neutron client 2.3.9
18:48:15 <SumitNaiksatam> this was before we had a stable branch for the client
18:48:33 <SumitNaiksatam> the rest of OpenStack Juno packages use neutronclient 2.3.12
18:48:48 <SumitNaiksatam> and 2.3.9 and 2.3.12 dont seem to be compatible
18:49:28 <SumitNaiksatam> so far we have been able to get around this by pinning to 2.3.9 in devstack
18:49:46 <rkukura> Shouldn’t we depend on >= 2.3.X and < 2.4, where 2.3.x is the version we test with?
18:50:02 <SumitNaiksatam> rkukura: yeah
18:50:30 <SumitNaiksatam> rkukura: the point i am trying to bring up is the we might be sitting on a ticking time bomb
18:50:43 <ransari> <SumitNaiksatam>: Will look at this: https://review.openstack.org/#/c/221898/
18:50:47 <SumitNaiksatam> and now that we have a separate stable/juno branch for the client
18:51:15 <SumitNaiksatam> we should move our client to depend on neutron client 2.3.12 (as other openstack packages)
18:51:35 <SumitNaiksatam> rkukura: i just want to make sure that this will not have any unintended side effects with existng packages
18:51:37 <rkukura> SumitNaiksatam: Shouldn’t we let that float upwards?
18:51:54 <SumitNaiksatam> ransari: great, thanks
18:51:57 <rkukura> I.e. >= 2.3.12, < 2.4?
18:52:04 <SumitNaiksatam> rkukura: right
18:52:14 <SumitNaiksatam> rkukura: but today we are at 2.3.9
18:52:27 <SumitNaiksatam> and to move to 2.3.12, we need some fixes
18:52:53 <SumitNaiksatam> which i wil post, however, i just wanted a sanity check from the team here, that doing this will not have any impact on existing installations
18:54:22 <SumitNaiksatam> so if you cant think of anything, then may be i will go ahead with the changes
18:54:44 <SumitNaiksatam> we have also updated our devstack install process
18:54:57 <SumitNaiksatam> we no longer have a separate branch for devstack
18:55:12 <SumitNaiksatam> we are patching the upstream devstack branch
18:55:37 <SumitNaiksatam> #link https://github.com/group-policy/gbp-devstack
18:55:49 <SumitNaiksatam> this is still not the plugin approach that we should be following
18:56:11 <SumitNaiksatam> however, there are some quirks that need a little bit of ironing out before we get to that
18:56:38 <SumitNaiksatam> but even with this patch approach, we no loner have to merge changes from teh upstream devstack branch
18:57:19 <SumitNaiksatam> mageshgv: we also update the service chain exercise scripts on stable/juno, right?
18:57:33 <mageshgv> SumitNaiksatam: yes, we have it in stable/juno as well
18:57:35 <SumitNaiksatam> *updated
18:57:50 <mageshgv> SumitNaiksatam: right, its in sync with master
18:57:51 <SumitNaiksatam> mageshgv: great, so we are completely in sync on that branch
18:57:56 <SumitNaiksatam> mageshgv: great
18:58:14 <SumitNaiksatam> 2 mins left, anything else we want to discuss today?
18:58:45 <SumitNaiksatam> alright, thanks everyone for your time
18:58:52 <ivar-lazzaro> thanks! bye
18:58:52 <SumitNaiksatam> bye!
18:58:53 <rkukura> I should mention that I will be on PTO Monday and Tuesday, and am not likely to answer emails those days.
18:59:04 <SumitNaiksatam> rkukura: okay
18:59:17 <SumitNaiksatam> #endmeeting