18:01:24 <SumitNaiksatam> #startmeeting networking_policy
18:01:24 <openstack> Meeting started Thu Mar 19 18:01:24 2015 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:28 <openstack> The meeting name has been set to 'networking_policy'
18:01:45 <Yi> hi
18:01:52 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#March_19th.2C_12th_2015
18:02:18 <SumitNaiksatam> #info kilo-2 was released as planned: #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/059236.html
18:02:43 <SumitNaiksatam> things which did not make it into kilo-2 now moved to kilo-3
18:02:56 <SumitNaiksatam> #info kilo-3 deadline is April 15th
18:03:09 <SumitNaiksatam> so we are the real business end of the release now! ;-)
18:04:04 <SumitNaiksatam> we also had the PTL elections (per project requirements), and the results were declarded: #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/059317.html
18:04:17 <SumitNaiksatam> thanks to malini for shepherding the elections
18:04:18 <rkukura> congrats SumitNaiksatam!
18:04:27 <Yi> congrats!
18:04:39 <SumitNaiksatam> rkukura: yi: thanks ;-)
18:04:40 <mageshgv> Congrats SumitNaiksatam!!
18:04:43 <SumitNaiksatam> mageshgv: thanks
18:04:51 <SumitNaiksatam> so lets start with the standing agenda items
18:04:58 <SumitNaiksatam> #topic Bugs
18:05:07 <SumitNaiksatam> at least one critical bug this time:
18:05:15 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1433530
18:05:16 <openstack> Launchpad bug 1433530 in Group Based Policy "GBP Kilo release should be in sync with Neutron Kilo" [Critical,New] - Assigned to Magesh GV (magesh-gv)
18:05:26 <ivar-lazzaro> hi
18:05:34 <SumitNaiksatam> we have known this for a while, so mageshgv thanks for jumping on this
18:06:03 <SumitNaiksatam> #link https://review.openstack.org/165377
18:07:25 <SumitNaiksatam> i agree with ivar-lazzaro’s comment there, that should be added right away so that we can catch all other issues with the neutron integration at least at the UT level
18:07:55 <SumitNaiksatam> mageshgv: are you comfortable with this or is it blowing up into too many changes?
18:08:28 <mageshgv> SumitNaiksatam: It looks pretty straight forward for the server
18:08:36 <SumitNaiksatam> mageshgv: okay
18:09:16 <SumitNaiksatam> on the client side also, there are similar oslo changes, and we should do that in parallel to bump up the neutron client dependency to 2.3.10
18:09:41 <mageshgv> #link https://review.openstack.org/#/c/165378/
18:09:44 <SumitNaiksatam> mageshgv: i believe you need this for your floating IP support impl as well?
18:09:57 <SumitNaiksatam> mageshgv: oh nice, sorry i did not catch that
18:09:57 <mageshgv> The client has some tricky changes though
18:10:17 <SumitNaiksatam> mageshgv: hmmm, ok
18:10:41 <mageshgv> As for floating IP, I can post a WIP patch may be tomorrow
18:10:57 <SumitNaiksatam> mageshgv: sweet, lets get to that in the specs discussion
18:11:32 <SumitNaiksatam> ivar-lazzaro: you wanted to discuss: #link https://bugs.launchpad.net/group-based-policy/+bug/1432816 ?
18:11:33 <openstack> Launchpad bug 1432816 in Group Based Policy "inconsistent template ownership during chain creation" [Undecided,New] - Assigned to Ivar Lazzaro (mmaleckk)
18:11:43 <ivar-lazzaro> SumitNaiksatam: yep
18:12:07 <ivar-lazzaro> To give a quick summary, the problem in on SC instance ownership
18:13:14 <ivar-lazzaro> a chain can be triggered in many different ways... By someone providing a PRS, or consuming it
18:13:25 <ivar-lazzaro> or even by an admin changing the PRS rules
18:13:40 <SumitNaiksatam> ivar-lazzaro: true
18:13:52 <ivar-lazzaro> Even though the intent is the same, the final state diverges depending on the user that triggers the chain
18:14:20 <ivar-lazzaro> for example, suppose you have a shared PRS, and TenantA provides it
18:14:40 <ivar-lazzaro> TenantB consuming it will trigger the chain, and TenantB will be the owner of the SC instance
18:15:13 <ivar-lazzaro> However, if TenantB was previously consuming the chain, and then TenantA triggered the instance by providing the same PRS
18:15:24 <SumitNaiksatam> ivar-lazzaro: mageshgv: shouldn’t the SC intance be always owned by admin (since its an internal artifact)? or does that cause issues with sharing due to associations with other resources?
18:15:37 <ivar-lazzaro> In this case the SC instance (and the HEAT stacks) will be owned by tenantA
18:16:06 <ivar-lazzaro> This becomes a problem when a given tenant starts the action, and another one do the opposite (eg. destroy the chain)
18:16:27 <ivar-lazzaro> this would fail because the tenant triggering the destruction is not owning the chain
18:17:02 <ivar-lazzaro> SumitNaiksatam: that's the question I want to bring up... who has to own the chain?
18:17:17 <ivar-lazzaro> SumitNaiksatam: the admin? The provider? The consumer?
18:17:40 <Yi> ivar-lazzaro: what's the difference between SFC case and other cases?
18:17:42 <mageshgv> SumitNaiksatam: admin owning the SC instance does solve this issue.
18:17:46 <hemanthravi> in case of admin that would be a parent PRS with the SC, is that right?
18:18:06 <SumitNaiksatam> hemanthravi: there is no PRS hierarchy issue here
18:18:23 <ivar-lazzaro> Yi: that with SFC some heat stacks are created, and owned by a given tenant
18:18:32 <mageshgv> ivar-lazzaro: the owner should not be the consumer IMO. It can be either the admin or the provider
18:18:41 <ivar-lazzaro> Yi: and they cannot be destroyed unless the very same tenant triggers the disruption
18:18:48 <ivar-lazzaro> mageshgv: I agree
18:19:28 <hemanthravi> mageshv: agree
18:19:32 <SumitNaiksatam> hemanthravi: the issue is that we create service chain instances internally (triggered by some other user actions), and currently we dont consistently use the same tenant to create/modify the SC instance
18:19:43 <ivar-lazzaro> The advantage of having the provider owning it is that he can go and modify manually the instances if available
18:19:59 <SumitNaiksatam> ivar-lazzaro: true but that would be concern too, no?
18:20:04 <ivar-lazzaro> But it will hit his/her quota (in the VM case for example)
18:20:49 <ivar-lazzaro> The advantage of having the admin as the owner is that all the chains belong to the same place, but they won't be visible by the tenants
18:21:13 <SumitNaiksatam> ivar-lazzaro: they can always be visible, right?
18:21:20 <mageshgv> ivar-lazzaro, SumitNaiksatam: may be we can even consider something similar to this #link https://review.openstack.org/#/c/101281/
18:21:30 <ivar-lazzaro> SumitNaiksatam: no unless you share them
18:21:37 <SumitNaiksatam> ivar-lazzaro: its just that the non-admin user wont be able to modify
18:21:53 <SumitNaiksatam> ivar-lazzaro: true, or we could add another user
18:22:05 <yapeng> ivar-lazzaro: but we can't assume that admin always as owner of chain, right?
18:22:07 <SumitNaiksatam> user -> role, i was going to mention that earlier
18:22:13 <ivar-lazzaro> SumitNaiksatam: even in that case, providers and consumers won't be able to see the instances
18:22:15 <igordcard> ivar-lazzaro: but then the admin would need to pre-create all possible chains, right?
18:22:30 <ivar-lazzaro> yapeng: it could be a configurable user
18:22:43 <SumitNaiksatam> yapeng: this is chain instance that is internally created
18:22:44 <ivar-lazzaro> yapeng: which is an Admin and which can create Heat templates
18:23:23 <SumitNaiksatam> igordcard: hi, good to see you join the meeting - to your question, no, not required to pre-create
18:23:31 <ivar-lazzaro> But there are other issues to consider, like how a VM (NFV) could be attached to one or more networks belonging to different tenant
18:23:52 <SumitNaiksatam> ivar-lazzaro: here is my suggestion (dont mean to prolong the discussion) -
18:24:26 <SumitNaiksatam> ivar-lazzaro: i think people need a little more time to think about this, so i believe this is an excellent topic to bring up on the -dev ML
18:24:40 <ivar-lazzaro> SumitNaiksatam: +1
18:24:44 <SumitNaiksatam> and we can have the discussion there and try to wrap this up in a couple of days, sound okay?
18:24:51 <mageshgv> +1
18:24:58 <igordcard> SumitNaiksatam: +1
18:25:33 <SumitNaiksatam> okay good, i believe ivar-lazzaro has given it the most thought, so i more inclined to go with his approach, but there are other groups working on similar problem, so lets see if we hear from them
18:25:59 <SumitNaiksatam> ivar-lazzaro: mageshgv: igordcard yapeng Yi hemanthravi: thanks for your input on this
18:26:35 <SumitNaiksatam> ivar-lazzaro: i bumped the other bug assigned to you to Critical (support for redirect in external policy)
18:26:45 <SumitNaiksatam> ivar-lazzaro: but i believe you have that covered
18:26:52 <ivar-lazzaro> SumitNaiksatam: thanks, there's already a patch there
18:27:03 <ivar-lazzaro> which brings up another question actually
18:27:10 <SumitNaiksatam> ivar-lazzaro: ah okay, #link https://review.openstack.org/164920
18:27:24 <ivar-lazzaro> do we have time to discuss this?
18:27:30 <SumitNaiksatam> as matter of sanity, we will discuss every critical bug in this meeting
18:27:32 <SumitNaiksatam> ivar-lazzaro: yes
18:27:40 <SumitNaiksatam> critical bug is show-stopper
18:27:41 <ivar-lazzaro> ok
18:27:43 <ivar-lazzaro> #link https://bugs.launchpad.net/group-based-policy/+bug/1432779
18:27:44 <openstack> Launchpad bug 1432779 in Group Based Policy "redirect actions don't work with external policies" [Critical,Confirmed] - Assigned to Ivar Lazzaro (mmaleckk)
18:28:12 <ivar-lazzaro> The quick summary is that chains are not triggered when one of the actors is an External Policy
18:28:35 <ivar-lazzaro> which is obviously needed (ie. LB in front of Web access)
18:28:48 <SumitNaiksatam> ivar-lazzaro: okay, i believe this was an oversight in the earlier integration between the external connectivity and service chaining?
18:29:00 <ivar-lazzaro> SumitNaiksatam: yes
18:29:06 <SumitNaiksatam> and it was discovered during recent integration testing
18:29:29 <ivar-lazzaro> In my current implementation, a chain can only be consumed by an External Policy
18:29:29 <SumitNaiksatam> ivar-lazzaro: thanks for catching that and jumping on it
18:30:10 <ivar-lazzaro> when an external policy provides a chain, it's managed like a normal ALLOW action
18:30:11 <SumitNaiksatam> just a friendly suggestion to everyone, please add “group-based-policy-core” to the reviewer’s list when you submit a patch
18:30:23 <ivar-lazzaro> SumitNaiksatam: woops
18:30:26 <SumitNaiksatam> ivar-lazzaro: right
18:30:59 <SumitNaiksatam> once you add that alias, all cores will get automatically added and it will show on the review dashboards
18:31:02 <igordcard> SumitNaiksatam: ahh, thanks
18:31:06 <SumitNaiksatam> ivar-lazzaro: sorry did not mean to interrupt
18:31:17 <ivar-lazzaro> I was wondering if there are any use cases for which we want to enable chaining also on a EP *providing* a PRS
18:31:25 <ivar-lazzaro> SumitNaiksatam: np, that was a good observation
18:32:52 <SumitNaiksatam> ivar-lazzaro: but seems like you have this covered
18:33:08 <ivar-lazzaro> I don't see an EP providing a Load Balancer for instance... But I can see it providing an IDS
18:33:11 <SumitNaiksatam> ivar-lazzaro: good question, i have not thought through that
18:33:34 <SumitNaiksatam> ivar-lazzaro: not sure about IDS, i think hemanthravi might have more insight here
18:33:48 <SumitNaiksatam> ivar-lazzaro: but i would suggest that this is also a great question for the -dev ML
18:34:04 <Yi> ivar-lazzaro: why no LB?
18:34:35 <ivar-lazzaro> Yi: well, the external policy is the rest of the world, Who are the members of the load balancer in that case?
18:35:21 <ivar-lazzaro> Yi: in the RMD case, the porta on the External Network are usually router interfaces
18:35:24 <hemanthravi> ivar: In case the EP is for provider resources such as a logging service, etc the IDS might not be required
18:35:41 <igordcard> if service chaining evolves to support other kinds of services, even provided by VMs, it may make sense for future use cases to have chaining on provider EPs..
18:35:53 <SumitNaiksatam> hemanthravi: good point, “logging service” seems like a good example
18:36:01 <SumitNaiksatam> igordcard: +1
18:36:03 <ivar-lazzaro> hemanthravi: logging seems a good case
18:36:24 <SumitNaiksatam> ivar-lazzaro: lets take this to the ML as well ;-)
18:36:35 <SumitNaiksatam> ivar-lazzaro: sorry, dont mean to delay things
18:36:44 <ivar-lazzaro> roger that
18:36:45 <SumitNaiksatam> ivar-lazzaro: but good to have broader discussion
18:37:05 <hemanthravi> don't think we need to support SC for EP provider at this time
18:37:07 <ivar-lazzaro> SumitNaiksatam: it makes sense to me, it's a great help for making decisions
18:37:17 <SumitNaiksatam> ivar-lazzaro: okay
18:37:18 <ivar-lazzaro> SumitNaiksatam: the more use cases people have in mind, the better
18:37:41 <SumitNaiksatam> hemanthravi: okay, lets chime in on the ML (ivar-lazzaro will send email and start the discussion)
18:37:52 <SumitNaiksatam> any other bugs anyone wants to discuss?
18:38:31 <SumitNaiksatam> #topic Functional/Integration Tests
18:38:44 <SumitNaiksatam> #link https://review.openstack.org/#/c/161511 was approved
18:38:53 <SumitNaiksatam> and then there was a follow up patch as well
18:39:29 <SumitNaiksatam> anyway, summary is that we if you do a “check experimental” it will trigger a job from the openstack infra
18:39:52 <SumitNaiksatam> the actual job that needs to be run is being configured in gate-hook that resides on teh GBP side:
18:40:00 <SumitNaiksatam> #link https://review.openstack.org/#/c/161532
18:40:13 <SumitNaiksatam> i am working on this part
18:40:35 <SumitNaiksatam> apologies on the slower progress on this, i am learning by trial and error
18:40:44 <SumitNaiksatam> is jishnu here?
18:41:13 <SumitNaiksatam> he is working on adapting his test suite to be triggered from this gate job, would have been good to have his update
18:41:29 <SumitNaiksatam> any questions on this?
18:42:06 <SumitNaiksatam> we wil soon get to a point where we will require submitting some functional/integration tests with every new feature
18:42:10 <SumitNaiksatam> and that is a good thing ;-)
18:42:50 <SumitNaiksatam> if you have spare cycles please feel free to jump in on this activity (ping me offline)
18:43:03 <SumitNaiksatam> #topic Packaging update
18:43:08 <SumitNaiksatam> rkukura: over to you
18:43:47 <SumitNaiksatam> sorry, i dont have the new release of the stable/juno yet
18:43:56 <rkukura> Now that we have a stable/juno update, I need to update the Fedora and RDO packaging. Should get to that over the next week or so.
18:44:11 <rkukura> SumitNaiksatam: I thought you did - sorry
18:44:27 <rkukura> forgot we were still trying to get the policy.json fix in
18:44:53 <SumitNaiksatam> rkukura: yeah, i was exploring mageshgv’s comment
18:45:13 <SumitNaiksatam> exploring -> investigating
18:45:21 <SumitNaiksatam> mageshgv: i will catch up with you offline
18:45:39 <SumitNaiksatam> #link https://review.openstack.org/#/c/165294/1/setup.cfg
18:45:44 <mageshgv> SumitNaiksatam: okay, we can discuss on this offline
18:45:51 <rkukura> It would be great if we could use the policy_dirs approach rather than requiring manual merging of the files.
18:46:05 <SumitNaiksatam> rkukura: that is not clear to me, but may be i am missing something
18:46:30 <SumitNaiksatam> mageshgv: thanks for the suggestion though, since i was not even aware of this possibility
18:46:51 <SumitNaiksatam> rkukura: thanks for the update
18:46:58 <rkukura> mageshgv: you said “this will cause issues” so I’m not assuming it possible - just that it would be nice
18:47:10 <SumitNaiksatam> #topic GBP Project Proposal
18:47:21 <SumitNaiksatam> #undo
18:47:22 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x8e5f350>
18:48:12 <rkukura> Lets followup on the gerrit review
18:48:29 <SumitNaiksatam> rkukura: okay
18:48:34 <SumitNaiksatam> #topic GBP Project Proposal
18:48:42 <SumitNaiksatam> we put the proposal in WIP
18:49:16 <SumitNaiksatam> since we wanted to address the comments made - (1) PTL election, (2) gate that has more than just UTs
18:49:28 <SumitNaiksatam> i believe we are past (1) now
18:49:47 <SumitNaiksatam> once we sort out (2) (and we are getting closer on that), we will remove the WIP
18:50:09 <SumitNaiksatam> just FYI - the TC meets every tuesday to discuss these type of things
18:50:29 <SumitNaiksatam> and we need to request being on their agenda 4 business days prior to the meeting
18:50:46 <SumitNaiksatam> so anyone has any thoughts/suggestions/comments on this please let me know
18:50:55 <SumitNaiksatam> i am rushing here a little but since we have only 10 mins left
18:51:13 <SumitNaiksatam> our favorite topic -
18:51:17 <SumitNaiksatam> #topic Re-factor Group Based Policy with Neutron RESTful APIs
18:51:23 <SumitNaiksatam> Yi: yapeng: over to you
18:51:47 <SumitNaiksatam> sorry i havent reviewed the latest changes
18:52:14 <SumitNaiksatam> how close are we to addressing the last round of review suggestions by ivar-lazzaro and rkukura?
18:52:39 <yapeng> we are wrapping up the UTs. I updated one patch and ready for review.
18:53:07 <SumitNaiksatam> yapeng: #link https://review.openstack.org/159725 right?
18:53:17 <yapeng> Yes
18:53:23 <SumitNaiksatam> okay
18:53:34 <SumitNaiksatam> yapeng: Yi: any blockers?
18:53:50 <Yi> SumitNaiksatam: on my side, I finished the mixin that Ivar suggested
18:53:57 <SumitNaiksatam> Yi: sweet!!
18:54:07 <Yi> but on patching the UT, I have some issues
18:54:08 <ivar-lazzaro> nice
18:54:34 <Yi> I have create_resource/update_resource/delete_resource patched
18:54:50 <Yi> but got issue with get_resource and get_resources
18:55:09 <Yi> 1. for get_resource, or show_resource
18:55:37 <Yi> it somehow cannot get along with the gbp plugin operations
18:56:10 <SumitNaiksatam> ivar-lazzaro: can i request you to spare a few minutes to help  Yi  with this in #openstack-gbp after this meeting?
18:56:21 <ivar-lazzaro> SumitNaiksatam: sure
18:56:26 <Yi> for example, getting policy target would be fine if I patch the get_port through plugin call
18:56:38 <SumitNaiksatam> ivar-lazzaro: thanks
18:56:50 <Yi> but if I patch the get_port with WSGI, get_policy_target will fail
18:56:56 <SumitNaiksatam> Yi: okay
18:57:16 <SumitNaiksatam> Yi: seems like a slightly longer discussion, if you dont mind lets pick it up in #openstack-gbp immediately after this
18:57:24 <Yi> SumitNaiksatam, ivar-lazzaro: that would be great. thanks!
18:57:41 <SumitNaiksatam> Yi: nice, thanks for persistence on this!
18:57:58 <SumitNaiksatam> #topic Floating IP support
18:58:00 <SumitNaiksatam> #link https://review.openstack.org/157298
18:58:12 <SumitNaiksatam> mageshgv: i believe you mentioned you will be posting a WIP tomorrow?
18:58:25 <SumitNaiksatam> mageshgv: will you be updating the spec accordingly?
18:58:51 <mageshgv> SumitNaiksatam: yes, I will post the patch tomorrow
18:59:27 <mageshgv> once we go over the patch and see that the current approach makes sense at a high level, I can update the bp
19:00:04 <SumitNaiksatam> mageshgv: okay, but we need to iterate quickly on this
19:00:37 <SumitNaiksatam> mageshgv: lets identify a couple of point people (in terms of reviewers) that will work with you closely on this to move this forward
19:00:59 <SumitNaiksatam> mageshgv: thanks for the update
19:01:04 <mageshgv> SumitNaiksatam: yes, it should be faster to iterate now that we have a rough implementation
19:01:14 <SumitNaiksatam> #topic Cross Project Liaisons
19:01:26 <SumitNaiksatam> rkukura: stepped up for being a liaison for Oslo and Nova
19:01:52 <SumitNaiksatam> we are still looking for liaisons for other projects, with Keystone and Neutron being a priority
19:01:55 <rkukura> nothing to report yet though
19:01:57 <SumitNaiksatam> please ping me if you would like to
19:02:02 <SumitNaiksatam> rkukura: thanks!
19:02:19 <SumitNaiksatam> #topic Open Discussion
19:02:24 <SumitNaiksatam> we are two minutes over
19:02:35 <SumitNaiksatam> anything we missed that you want to bring up?
19:03:27 <SumitNaiksatam> kilo-3 is crunch time, so lets lock in our focus! ;-)
19:03:33 <SumitNaiksatam> okay thanks everyone for attending today
19:03:40 <SumitNaiksatam> bye
19:03:44 <rkukura> thanks SumitNaiksatam!
19:03:45 <mageshgv> nye
19:03:47 <igordcard> bye
19:03:48 <rkukura> bye
19:03:48 <mageshgv> bye
19:03:48 <hemanthravi> bye
19:03:52 <SumitNaiksatam> #endmeeting