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