18:00:28 <SumitNaiksatam> #startmeeting networking_policy
18:00:28 <hemanthravi> hi
18:00:28 <openstack> Meeting started Thu Jun  2 18:00:28 2016 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:32 <openstack> The meeting name has been set to 'networking_policy'
18:00:50 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#June_2nd.2C_May_26th.2C_2016
18:01:07 <SumitNaiksatam> is songole here?
18:01:35 <SumitNaiksatam> if he is around we could discuss the bugs he entered
18:01:35 <hemanthravi> let me get him
18:01:39 <SumitNaiksatam> yesterday
18:01:52 <SumitNaiksatam> let me start with the testing
18:01:55 <SumitNaiksatam> #topic Testing
18:02:11 <SumitNaiksatam> an update on the gate test job for Rally
18:02:18 <SumitNaiksatam> it was broken for about a month
18:02:33 <hemanthravi> SumitNaiksatam: songole will be back in a few min
18:02:35 <SumitNaiksatam> i have fixed the Rally branch now, so the job is running again
18:02:45 <SumitNaiksatam> hemanthravi: np, we will take that up when he is here
18:03:28 <SumitNaiksatam> so please take a look at the rally job results when you review patches
18:04:02 <SumitNaiksatam> please note that there are some tests which are not returning 100% success, and i think we had planned to remove those tests because they were not framed correctly
18:04:17 <SumitNaiksatam> i have it on my TODO list to do that clean up
18:05:08 <SumitNaiksatam> #topic QoS impl
18:05:17 <SumitNaiksatam> #link https://review.openstack.org/#/c/301701/
18:05:33 <SumitNaiksatam> i think igordcard updated the patch but is still not passing the integration gate
18:05:54 <igordcard> SumitNaiksatam: it's passing..
18:05:58 <SumitNaiksatam> and also needs the devref that was requested
18:06:24 * tbachman joins the part
18:06:26 <tbachman> party
18:06:33 <SumitNaiksatam> igordcard: its passing py27 but not gate-group-based-policy-dsvm-functional
18:06:39 <SumitNaiksatam> tbachman: hi
18:06:41 <tbachman> SumitNaiksatam: hi!
18:06:44 <tbachman> sorry I’m late
18:06:45 <tbachman> (again)
18:06:55 <SumitNaiksatam> tbachman: np
18:07:02 <igordcard> SumitNaiksatam: oh, I thought those always failed no matter what
18:07:13 <SumitNaiksatam> igordcard: no, both those should pass
18:07:22 <SumitNaiksatam> igordcard: it fails in Juno
18:07:38 <SumitNaiksatam> igordcard: the second one (rally) was failing for some time, but i have fixed it now
18:07:55 <igordcard> SumitNaiksatam: where is the request for devref?
18:07:56 <SumitNaiksatam> igordcard: and ideally we want the qos impl to be tested in the gate-group-based-policy-dsvm-functional job too
18:08:30 <igordcard> SumitNaiksatam: there is no QoS neutron support in Juno
18:08:34 <SumitNaiksatam> igordcard: i put it in the comment on May 26th
18:08:48 <SumitNaiksatam> igordcard: yes sure, we dont need to backport this to Juno
18:09:16 <igordcard> SumitNaiksatam: oh, my bad, I only read the file comments
18:09:32 <SumitNaiksatam> igordcard: np, i guessed as much (you addressed the inline comments)
18:10:01 <SumitNaiksatam> igordcard: i think it will be easier for the other folks in the team to try this out once you have those two things
18:10:40 <SumitNaiksatam> if there are no questions for igordcard we can let him go, we are standing between him and his dinner ;-)
18:10:44 <igordcard> SumitNaiksatam: alright
18:10:56 <SumitNaiksatam> igordcard: thanks
18:10:59 <igordcard> SumitNaiksatam: lol :p
18:11:04 <SumitNaiksatam> #topic Packaging
18:11:13 <SumitNaiksatam> rkukura: thanks for joining in spite being on PTO
18:11:20 <SumitNaiksatam> rkukura: anything to update here?
18:11:30 <rkukura> no problem, and no update on packaging
18:11:37 <SumitNaiksatam> rkukura: okay
18:11:56 <rkukura> I need to find someone at Red Hat who will respond regarding the Delorean integration
18:11:58 <SumitNaiksatam> we ran into an issue with using GBP with Fuel
18:12:06 <SumitNaiksatam> rkukura: true :-)
18:12:25 <rkukura> right, I was discussing the fuel issue with tbachman
18:12:41 <SumitNaiksatam> the issue we ran into with Fuel was that it patches released versions, and some of our monkey patches are incompatible
18:12:42 <rkukura> and SumitNaiksatam, sorry
18:12:53 <tbachman> rkukura: :)
18:12:58 <SumitNaiksatam> rkukura: tbachman any thoughts?
18:13:08 <tbachman> SumitNaiksatam: no great idea just yet
18:13:12 <tbachman> it’s a tricky one
18:13:13 <SumitNaiksatam> err, i mean any solutions? :-P
18:13:32 <tbachman> as you pointed out, it would be nice to be able to divine a version somehow
18:13:46 <SumitNaiksatam> tbachman: okay
18:13:51 <rkukura> monkey patching like we do is evil
18:13:56 * tbachman nods
18:14:02 <SumitNaiksatam> rkukura: i knew you were going to say that! :-)
18:14:04 <rkukura> so lets not blame fuel
18:14:05 <tbachman> lol
18:14:30 <SumitNaiksatam> rkukura: yeah, no blame game
18:14:35 <SumitNaiksatam> but problem remains
18:14:54 <rkukura> its my monkey patch anyway, so I could only blame myself
18:15:10 <SumitNaiksatam> rkukura: it was a team decision to go that way
18:15:18 <rkukura> SumitNaiksatam: of course
18:15:42 <rkukura> This particular one was intended to be short term, right?
18:15:56 <SumitNaiksatam> rkukura: right, and good point
18:16:03 <SumitNaiksatam> rkukura: we can perhaps revisit if its really required
18:16:07 <rkukura> We thought we might be hitting infinite loops, and wanted to see if this happens in the field
18:16:20 <SumitNaiksatam> perhaps the infinite loop would not manifest any more
18:16:22 <rkukura> do we know if this has been happening?
18:16:56 <SumitNaiksatam> rkukura: it happens if you go and try to delete neutron resources for which corresponding GBP resources still exist
18:17:31 <SumitNaiksatam> this is of course not supported and no one should be doing it, but we wanted to get out of the infinite loop situation
18:17:38 <rkukura> SumitNaiksatam: thanks for the reminder - this was due to the TX failing due to a FK, right?
18:17:47 <SumitNaiksatam> rkukura: yeah
18:17:59 <rkukura> Or maybe not? Do we do FKs to neutron?
18:17:59 <SumitNaiksatam> so the thing is that we are probably covered as far as Fuel is concerned even without the monkey patch
18:18:01 <tbachman> FK?
18:18:10 <rkukura> foreign key
18:18:12 <tbachman> ah
18:18:31 <SumitNaiksatam> however this will still break with RHEL install
18:18:43 <SumitNaiksatam> break -> infinite loop
18:19:24 <SumitNaiksatam> my concern is that there might be a solution for this particular patch, but we have patched other things as well
18:19:58 <SumitNaiksatam> and it may or may not be straight forward to deal with those (if there is problem with those as well)
18:20:25 <SumitNaiksatam> anyway, perhaps we need some more offline conversation on this before next week’s meeting
18:20:52 <SumitNaiksatam> thanks for the input from everyone, and thanks tbachman for digging up all the details
18:21:03 <tbachman> SumitNaiksatam: wish I hadn’t
18:21:07 * tbachman sticks head in sand
18:21:14 <SumitNaiksatam> tbachman: lol!
18:21:16 <rkukura> I checked, and we do have FKs for neutron resources in our schema
18:21:24 <SumitNaiksatam> rkukura: right
18:21:49 <SumitNaiksatam> #topic NFP Impl patches
18:22:01 <SumitNaiksatam> hemanthravi: songole: hi
18:22:12 <hemanthravi> update on nfp.
18:22:23 <SumitNaiksatam> hemanthravi: yes please go ahead
18:22:40 <hemanthravi> gbp gate tests are running, added nfp tests to gate
18:22:48 <hemanthravi> using namespace based fw and lb
18:22:49 <SumitNaiksatam> hemanthravi: cool
18:22:59 <SumitNaiksatam> hemanthravi: which patch adds the gate test?
18:23:11 * SumitNaiksatam is lazy is to check ;-P
18:23:18 <hemanthravi> https://review.openstack.org/#/c/298385/83
18:23:35 <hemanthravi> exercises/lb.sh, fw.sh
18:24:07 <hemanthravi> https://review.openstack.org/#/c/309145/83 has a README-NFP to try out nfp with devsatck
18:24:29 <hemanthravi> missing one of the test scripts mentioned, will ask rajendra to commit it tonight
18:24:59 <hemanthravi> started adding content to the patches wiki https://wiki.openstack.org/wiki/GroupBasedPolicy/GerritQueries/NFP#NFP_Implementation_Patches
18:25:10 <hemanthravi> will complete this and work on the devref patches
18:25:58 <SumitNaiksatam> hemanthravi: just looked at the former patch where you mentioned the gate tests are added, looks promising
18:26:08 <SumitNaiksatam> hemanthravi: the README also looks good
18:26:14 <hemanthravi> the wiki lists the patches in the order to be reviewed, not all of them are required for the base mode without a service vm
18:26:24 <hemanthravi> will document this against the patches
18:26:48 <SumitNaiksatam> hemanthravi: yeah, but i guess we need to be on the last patch to be able to install and check
18:27:07 <SumitNaiksatam> hemanthravi: so at that point we would have pulled the code from all the patches
18:27:21 <hemanthravi> yes, need to install the last patch
18:27:26 <SumitNaiksatam> hemanthravi: so it will be good to have a description on all the patches in the wiki page right away
18:27:36 <hemanthravi> will install all the code, but won't be exerceised for the base mode
18:27:44 <SumitNaiksatam> hemanthravi: okay
18:27:58 <hemanthravi> the other code is required when you launch a service vm as we demod at the summit
18:28:19 <SumitNaiksatam> hemanthravi: but overall this is good progress, and looks like is its at least at the point where people can try it out
18:28:35 <SumitNaiksatam> hemanthravi: more information will further aid in reviewing
18:28:57 <hemanthravi> will do, hope to have most of it done over the weekend
18:29:39 <hemanthravi> will be helpful to get more reviews on the first 2 patches to start with
18:29:52 <SumitNaiksatam> hemanthravi: sure
18:30:06 <SumitNaiksatam> hemanthravi:  i do see fw.sh in the integration job logs, so good
18:31:30 <SumitNaiksatam> hemanthravi: one issue i am seeing right away is that the tests are leaving some service_profiles undeleted, not sure if the delete failed, or the test failed to delete
18:31:46 <SumitNaiksatam> base_mode_lb and base_mode_fw
18:32:00 <hemanthravi> will check on that
18:32:51 <SumitNaiksatam> hemanthravi: thanks, and for the update in general
18:33:01 <SumitNaiksatam> any questions for hemanthravi on NFP?
18:33:45 <SumitNaiksatam> hemanthravi: okay thanks much!
18:33:50 <SumitNaiksatam> #topic Bugs
18:33:54 <SumitNaiksatam> songole: hi
18:34:02 <songole> SumitNaiksatam: hi
18:34:15 <songole> I filed a few bugs yesterday
18:34:19 <SumitNaiksatam> we were discussing a bunch of bugs over the past few days
18:34:23 <SumitNaiksatam> songole: yes
18:34:39 <songole> Some of them I believe are high priority
18:34:42 <SumitNaiksatam> any particular ones you want to discuss here, get input from the team?
18:34:51 <SumitNaiksatam> songole:  okay, which ones?
18:35:08 <SumitNaiksatam> if you can copy-paste the launchpad link, the bot will do the rest
18:35:15 <songole> https://bugs.launchpad.net/group-based-policy/+bug/1588109
18:35:15 <openstack> Launchpad bug 1588109 in Group Based Policy "APIC mapping: Neutron router not created for E <--> W L3 policy" [Undecided,New]
18:35:57 <SumitNaiksatam> songole:  that is driver specific, lets check with ivar-lazzaro
18:36:11 <songole> ok
18:36:21 <ivar-lazzaro> yeah that is APIC specific
18:36:37 <ivar-lazzaro> don't think RMD has the same issue
18:36:41 <SumitNaiksatam> ivar-lazzaro: right
18:36:53 <SumitNaiksatam> ivar-lazzaro: what do you think is a reasonable solution here?
18:37:10 <ivar-lazzaro> what happens is that in apic mapping Neutron routers are created only when L3Ps are attached to ES
18:37:19 <SumitNaiksatam> ivar-lazzaro: right
18:37:25 <ivar-lazzaro> I think that we could create a "default" one
18:37:33 <ivar-lazzaro> that is never attached to a ES
18:37:45 <SumitNaiksatam> ivar-lazzaro: okay
18:37:53 <ivar-lazzaro> but I want to check with the author of the first patch here, to see if there's a compelling reason for not doing it
18:38:04 <SumitNaiksatam> ivar-lazzaro: makes sense
18:38:41 <SumitNaiksatam> ivar-lazzaro: should we assign this to you for now investigation (and you can later punt it to someone else if required)?
18:38:52 <SumitNaiksatam> *for investigation
18:39:08 <ivar-lazzaro> sure
18:39:14 <SumitNaiksatam> ivar-lazzaro: okay thanks
18:39:42 <SumitNaiksatam> songole: whats next on your list?
18:39:46 <songole> SumitNaiksatam: if it is an easy fix, can we prioritize it?
18:40:21 <SumitNaiksatam> songole: okay, in LP medium priority is default for driver patches
18:40:32 <SumitNaiksatam> default -> convention
18:40:49 <songole> SumitNaiksatam: ok
18:40:49 <SumitNaiksatam> songole: we can follow up offline to make progress on this
18:40:56 <songole> https://bugs.launchpad.net/group-based-policy/+bug/1588099
18:40:57 <openstack> Launchpad bug 1588099 in Group Based Policy "Neutron fip association doesn't work with service chains" [Undecided,New]
18:41:23 <songole> We discussed this offline and I summarized the discussion in the bug
18:41:38 <ivar-lazzaro> songole: not sure that should be a bug, since this was known at the time we made the implementation
18:41:52 <ivar-lazzaro> songole: also, that is broken for explicit association only
18:42:08 <ivar-lazzaro> songole: but yeah, we need to find a solution anyways
18:42:30 <songole> ivar-lazzaro: right
18:42:48 <songole> https://bugs.launchpad.net/group-based-policy/+bug/1588107
18:42:49 <openstack> Launchpad bug 1588107 in Group Based Policy "Automate allocation of fip and static ip for loadbalancer vip" [Undecided,New]
18:42:56 <SumitNaiksatam> songole: anyone in your team can work on the suggestion made by ivar-lazzaro with retrieving all routers, and finding the candidate router from that based on the reachability?
18:43:25 <songole> SumitNaiksatam: I will check.
18:43:39 <SumitNaiksatam> songole: i am referring to 1588099
18:44:02 <songole> got it.
18:45:01 <songole> 1588107 is about the same provider being used externally (n-s) and internally (e-w)
18:45:43 <songole> I need to check the behavior of ip-single nat-pool option
18:45:54 <SumitNaiksatam> songole: so for 1588107 what is your expectation?
18:47:34 <songole> The intent should be to allocate fixed ip and assign floating ip to it
18:48:05 <SumitNaiksatam> songole: so per our discussion, i am finding it hard to understand “2n'd option above just creates a floating IP which the consumer could directly use. It doesn't allocate a local ip.”
18:48:29 <SumitNaiksatam> songole: as you said, it will be helpful if you can confirm that is indeed the case
18:48:44 <songole> okay
18:48:47 <SumitNaiksatam> songole: thanks
18:49:05 <songole> SumitNaiksatam: I have another bug which I haven't filed yet
18:49:05 <SumitNaiksatam> songole: if that was not the case, and the local ip was getting allocated, this is not a bug any more?
18:49:35 <ivar-lazzaro> songole, SumitNaiksatam: the local IP is not allocated?
18:49:36 <songole> SumitNaiksatam: I will verify it
18:49:45 <ivar-lazzaro> meaning that there's no fixed IP in the LB VIP port?
18:50:21 <SumitNaiksatam> ivar-lazzaro: yes thats the claim, and i am not sure how that can be the case
18:50:26 <songole> ivar-lazzaro: that is my understanding based on the code.
18:50:37 <ivar-lazzaro> That would be a huge bug, probably in Neutron too
18:50:45 <ivar-lazzaro> yeah let's verify that :D
18:51:38 <songole> SumitNaiksatam: I believe proxy ptg is created by admin for the end user
18:52:14 <SumitNaiksatam> songole: admin can create proxy ptg
18:52:14 <songole> SumitNaiksatam: this is regarding a check to not allow cross tenant resource creation. this check only exists for neutron
18:52:24 <songole> and not for apic
18:52:54 <songole> because of it, a non admin tenant will not be able to launch service chain on neutron
18:53:01 <SumitNaiksatam> songole: finding it difficult to grok, perhaps you can file the bug, and it might be easier to explain there?
18:53:12 <songole> ok
18:53:23 <songole> https://github.com/openstack/group-based-policy/blob/master/gbpservice/neutron/services/grouppolicy/drivers/resource_mapping.py#L371
18:54:10 <ivar-lazzaro> is it because of _reject_cross_tenant_ptg_l2p ?
18:54:21 <songole> ivar-lazzaro: yes
18:54:47 <songole> I don't see a similar check for apic_mapping driver
18:55:00 <songole> https://github.com/openstack/group-based-policy/blob/master/gbpservice/neutron/services/grouppolicy/drivers/cisco/apic/apic_mapping.py#L806
18:56:26 <ivar-lazzaro> songole: we need to see the implications of doing that
18:56:27 <songole> ivar-lazzaro: is there a specific reason behind that validation?
18:57:22 <songole> ivar-lazzaro: validation is required but it can be relaxed for admin?
18:57:36 <ivar-lazzaro> songole: maybe it could
18:57:50 <ivar-lazzaro> so you want the subnet to be owned by the admin
18:57:55 <ivar-lazzaro> and the network by the tenant
18:58:05 <ivar-lazzaro> if Neutron allows that, I don't see why not
18:58:49 <songole> ivar-lazzaro: is it not an issue with apic mapping?
18:59:15 <SumitNaiksatam> songole: may be we can take this offline, you can create the bug
18:59:25 <songole> SumitNaiksatam: ok
18:59:25 <ivar-lazzaro> songole: APIC mapping has his own neutron driver
18:59:26 <SumitNaiksatam> we have to yield to the next meeting in a few seconds
18:59:51 <SumitNaiksatam> thanks all for joining!
19:00:07 <ivar-lazzaro> adieu!
19:00:09 <SumitNaiksatam> bye!
19:00:12 <songole> bye
19:00:13 <SumitNaiksatam> #endmeeting