18:08:07 #startmeeting networking_policy 18:08:08 Meeting started Thu Feb 5 18:08:07 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:08:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:08:12 The meeting name has been set to 'networking_policy' 18:08:23 #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#Feb_5th.2C_2015 18:08:42 nothing in terms of announcements at my end 18:08:52 anyone want to share anything upfront? 18:09:29 we will be mostly focussing on the kilo-1 work items 18:09:42 #topic Bugs 18:10:01 in the meeting agenda i have put links to the critical, high and medium bugs 18:10:15 thankfully we dont have any outstanding critical bugs 18:10:32 the links are to the bugs currently targeted for k-1 18:11:03 can you please take a look at the links and update the status for your assigned bugs? 18:11:50 there were a few bugs popping up on the deletion of resources (in the resource mapping driver) 18:12:31 are there any specific bugs anyone wants to discuss now (and/or the approach to fixing them)? 18:12:38 SumitNaiksatam: I started going through my bugs yesterday and adding comments 18:12:44 rkukura: okay 18:12:58 if we don’t think a fix will make k1 (in about a week), should we re-target k2? 18:13:09 rkukura: yes 18:13:22 rkukura: but some bugs might need to be fixed asap 18:13:51 rkukura: since they leave the system in an inconsistent state 18:14:13 rkukura: the ones where the deletion is of a resource is not allowed because there are associated resources 18:14:30 Unless they get backported to stable-juno, how would k1 get delivered? 18:14:33 but the deletion partially happens, and only the post-commit fails 18:14:48 rkukura: yes, we should backport those to stable/juno 18:15:33 About #link https://bugs.launchpad.net/group-based-policy/+bug/1414139 18:15:36 do we have a target for a stable/juno release? 18:16:01 #chair rkukura ivar-lazzaro s3wong mageshgv 18:16:02 Current chairs: SumitNaiksatam ivar-lazzaro mageshgv rkukura s3wong 18:16:16 rkukura: yes, its on launchpad 18:16:34 rkukura: also in the etherpad i shared in the last meeting #link https://etherpad.openstack.org/p/kilo-gbp-plan 18:17:09 ivar-lazzaro: go ahead 18:17:33 I’m not seeing a juno/stable release on either of those 18:17:58 RMD assumes implicit driver running, to give some context, when the RMD is running alone it accepts any object even if not linked properly (l2 without L3policy_id) 18:18:17 now the issue here is on where to do the check 18:18:39 If I were to check the missing link in the precommit, the implicit driver case would fail 18:18:41 rkukura: ah, i imagined you were asking about k-1 18:18:58 since all the pre-commits are executed before all the post commits 18:19:03 ivar-lazzaro: I think RMD should validate the needed resources 18:19:06 rkukura: we can decide in a stable/juno release date once we actually fix these bugs 18:19:35 rkukura: I'm wondering where though... Doing it in the precommit will break the ID case 18:19:43 rkukura: these have been pending for some time now, ideally we should have had another stable/juno by now, IMHO 18:19:53 ivar-lazzaro: What do you mean by “ID case”? 18:20:07 rkukura: *IMD 18:20:31 SumitNaiksatam: I defintely agree we should plan a 2014.2.1 release that fixes anything making 2014.2 unusable 18:20:37 rkukura: I mean that when you have IMD, all the precommit run before the postcommits. But the implicit link still doesn't exist at that time 18:21:07 IPD? 18:21:13 rkukura: so the RMD will raise an exception before the implicit driver has a chance to create the implicit resource 18:21:29 ivar-lazzaro: by IMD you mean IPD i think ;-) 18:21:45 implicit-policy-driver 18:21:46 rkukura, SumitNaiksatam: that one :D 18:22:12 ivar-lazzaro: I see what you mean 18:23:05 Maybe IPD needs to create the resources in pre-commit, but that would be within the TX. How about another pre-precommit phase for this? 18:23:38 rkukura: creating the object in the precommit may take too long 18:23:43 rkukura: and the DB lock may expire 18:24:00 Basically, one phase outside TX for validation and implicit creation, then the precommit phase in the TX, then a the postcommit phase outside 18:24:21 rkukura: one solution could be to make the RMD accept even non linked objects and resolve them only when actually linked 18:24:23 ivar-lazzaro: I’m suggesting we add a validate phase before the precommit phase 18:24:52 And this would be before any TX is started 18:25:09 rkukura: how would this solve the problem? 18:25:22 rkukura: the RMD will just raise the exception even earlier 18:25:47 The IPD would do all its work during the validate phase. 18:25:50 rkukura: the problem is that the IPD should create the reference *before* the RMD validation kicks on 18:26:07 Each driver’s validate phase would be called in order 18:26:22 The IPD (if used) would create implicit resources during the validate phase 18:26:41 The RMD would see they are there when it gets called in the validate phase 18:27:36 The issue I see with this is that there would be side effects if things get rolled back during or after the validate phase 18:27:37 rkukura: you would still need transactions to create the objects right? 18:28:09 rkukura: true 18:28:19 ivar-lazzaro: These transactions would be within the create methods of the resources that get implicitly created 18:28:56 the fact that the "initial" object doesn't exist in the DB yet is not a problem? 18:29:24 ivar-lazzaro: is this specifically an issue with regards to the l2p -> l3p association, or there are other places also where this can blow up? 18:29:27 ivar-lazzaro: I don’t think so - the L3P has no dependency on the L2P for which it is first created 18:29:56 SumitNaiksatam: everything that require the link to be in place. Also PTG -> L2P is broken 18:30:27 ivar-lazzaro: okay 18:30:42 In any case I think this is something we should document for Juno, and maybe that's not a good idea to backport the fix 18:30:43 I think this issue requires more thought, but seems like something we could address in kilo 18:30:58 rkukura: +1 18:30:59 ivar-lazzaro: rkukura: agree 18:31:02 But its probably not something we’d backport to stable/juno 18:31:22 ivar-lazzaro: +1 18:31:23 i think we can release note Juno with the requirement for the IPD to be configured 18:31:33 SumitNaiksatam: +1 18:32:33 stating the obvious - i think we should get this one fixed sooner, since it affects every critical path, and better to get it done early in the cycle 18:32:40 ivar-lazzaro: thanks for bringing it up for discussion here 18:32:52 I wonder if we should think about a TaskFlow based approach for kilo in place of the current ML2-like structure, where tasks have ways to undo themselves 18:33:06 rkukura: +1 18:33:36 that said we have other changes planned as well, so we can’t have too many structural changes in flight at the same time 18:34:00 we can decide which ones are of critical importance and prioritize accordingly 18:34:12 we currntly have a priority of tasks, but we can revisit 18:34:13 russellb: ++ 18:34:20 russellb: ops 18:34:23 rkukura: ++ 18:34:40 rkukura: do you have a feel for how much effort it would take to move to taskflow? 18:34:49 SumitNaiksatam: I wish I did 18:34:52 resources/time 18:34:54 rkukura: ok 18:35:26 i think we need a fix for this issue one way or the other 18:35:30 There are WIP patches for incorporating TaskFlow into ML2 - I’ll at least try to understand those by next week 18:35:36 rkukura: okay 18:36:07 We could probably do something with a validate phase in kilo and TaskFlow in L if necessary 18:36:14 #action rkukura to evaluate and report on the effort to migrate to taskflow 18:36:25 SumitNaiksatam: OK 18:36:42 ivar-lazzaro: in the meanwhile do you want to evaluate if there is any other workaround for this IPD issue? 18:37:05 or may be you already have 18:37:08 SumitNaiksatam: yup 18:37:23 ivar-lazzaro: rkukura: great 18:37:48 ok any other bugs that we want to discuss (or people having problems with making progress on fixing them)? 18:38:16 yes 18:38:25 rkukura: go ahead 18:39:03 The nova preexisting port deleteion fix is close to merging: https://review.openstack.org/#/c/126309/ 18:39:24 rkukura: okay good 18:39:26 rkukura: nice 18:39:38 Wouldn’t hurt for others to review that 18:39:56 this would still mean that we have to delete the policy targets (and the ports would get deleted at that time), right? 18:40:26 And we’ll need to think about how it effects us, and whether we want to encourage backporting it to nova’s stable/juno 18:40:57 We’d probably change the FK to not null on delete 18:41:08 rkukura: ok 18:41:15 could impact our users though so wanted to mention it 18:42:04 rkukura: okay, you mean since they use the port to spin up the VM? 18:43:06 however, the PT delete will take care of deletion of the port, right? 18:43:13 SumitNaiksatam: Actually, as long as they expliciltly delete the PT after killing the VM, they’ll be OK 18:43:20 rkukura: yeah 18:43:25 maybe a false alarm then 18:43:26 so that workflow does not change 18:43:44 good to know though 18:43:48 OK 18:43:50 okay we need to get to the next topic 18:43:53 #topic Re-factor Group Based Policy with Neutron RESTful APIs 18:44:11 #link https://review.openstack.org/#/c/153126 18:44:14 yapeng: hi 18:44:24 not sure if yi is around too 18:44:43 hi, Yi seems offline right now 18:44:47 yapeng: do you want to summarize what approach you are taking? (sorry to put you on the spot) 18:46:02 sure, Yi and I plan to add neutron RESTful API driver first, then modify resource mapping driver to use neutron RESTful APIs. 18:46:20 i briefly described it in the spec. 18:46:33 yapeng: i noticed that you mention adding it as a driver 18:46:48 yapeng: i was thinking of this more as a library 18:46:59 perhaps we are thinking the same think, not sure 18:47:24 others please chime in based on your experience so far (those who have worked on the GBP to Neutron integration) 18:47:27 yes. "library" maybe more accurate. I can make a change in the spec. 18:47:34 yapeng: thanks 18:48:02 yapeng: since for us a neutron driver means something slightly different (its current the resource mapping driver which does that) 18:48:12 SumitNaiksatam, yapeng: RMD is pretty much the only thing affected here, right? 18:48:12 *currently 18:48:26 s3wong: yes, most likely 18:48:35 Is there a need to support both direct calls and REST calls, selectable via config? 18:48:45 we need to get mageshgv’s input here as well 18:48:54 rkukura: good point, i thought about that one 18:48:59 SumitNaiksatam, yes, make sense to me now. 18:49:13 rkukura: but if we are a separate server, the direct calls will never work 18:49:19 s3wong: yes, RMD is the only thing to be changed. 18:49:38 rkukura: and direct calls will also assume the same service framework as of neutron, but that may or may not be the case 18:49:56 SumitNaiksatam: I agree but I’m concerned if we don’t succeed in moving to a separate server in kilo, REST calls could be a problem. 18:49:57 rkukura: i was thinking of the direct calls more of a transistion mechanism 18:49:59 GBP as independent API endpoint, and DB are two independent tasks related to this direct call to Neutron APIs 18:50:12 rkukura: yes, a transition mechanism to fall back on 18:50:24 SumitNaiksatam: REST calls would be mandatory if we want GBP as an independent server 18:50:37 s3wong: yes, this is the first step 18:50:52 rkukura: why would the REST call be a problem? because we can't make a REST call to ourselves? 18:50:58 If we are commiting to separate server for kilo, then I’m happy with just switching to REST client calls and not adding any additional complexity 18:51:07 mageshgv: i was asking also from the service chain driver impl perspective 18:51:28 REST calls to the same server going out through a loadbalancer and back could be a problem 18:51:32 Do we need to support also calls from Neutron to GBP? That's something that could be useful in the ML2 drivers that some of the vendor plugins have implemented for GBP 18:51:37 rkukura: but i think i agree with you that it might be a good option to have handy 18:51:53 SumitNaiksatam, is the seperate server chanage targeted for k-1? 18:52:13 yapeng: the evaluation of the separate server is definitely targeted for k-1, and perhaps more 18:52:23 yapeng: but that work has a dependency on what you are doing 18:52:35 SumitNaiksatam, rkukura: I see that GBP as independent API server (to pecan) as a K-1 milestone item? 18:52:50 s3wong: that is a proposal 18:52:56 Isn’t our K-1 in a week? 18:52:58 s3wong: may or may not be pecan right away 18:52:59 SumitNaiksatam: The service chain plugin also could reuse this new framework wherever needed. 18:53:05 rkukura: true :-) 18:53:23 10 days to be precise 18:53:39 It might be realistic to get the REST calls in K-1, but I think the pecan-based server will take more time 18:53:43 mageshgv: actually for service chain it is interesting. Service chain is a Neutron service plugin, right? 18:53:49 rkukura: yes 18:54:00 ivar-lazzaro: yes, some ML2 driver will need to call GBP APIs. 18:54:08 s3wong: so is GBP 18:54:29 mageshgv: and this GBP API server task would not change service chain's position, i.e., it would remain Neutron service plugin, right? 18:54:32 rkukura: but independent server need not be pecan-based from day one 18:54:45 we can have a transition path there as well 18:54:55 SumitNaiksatam, rkukura, s3wong, do you see a problem that ML2 driver calls GBP APIs? 18:54:56 SumitNaiksatam: True, but why not go straight to pecan? 18:55:25 s3wong, SumitNaiksatam: I assume when we have an independent server, the service chain plugin also would follow suit. Please correct me if you think otherwise 18:55:25 yapeng: I don’t see an issue for ML2 driver to call GBP via its REST client, as long as they are separate servers 18:55:47 yapeng: not really, other than having your ML2 drive dependent on GBP 18:56:04 mageshgv: I actually don't know --- hence asking :-) 18:56:04 rkukura: we might want to enable some of the other work to go in parallel that might need the indepedent server to be in place 18:56:31 rkukura, if this is the case, we need GBP server changes at the same time, right? 18:56:35 mageshgv: the idea would be invoking service chain would still be Neutron APIs 18:57:07 so based on the discussion here, my suggestion is that we try to design this in a way that rkukura suggested earlier 18:57:20 I think REST client calls in either or both directions within the same server should be OK for the interim 18:57:26 that is both REST and internal API call options are available (and config driven) 18:57:33 mageshgv: thus allowing yapeng and yi to uniformly migrate RMD from direct call to the new library calls 18:57:46 SumitNaiksatam: That’s probably safest, but maybe not necessary 18:57:51 rkukura: ok 18:57:58 lets comment on the spec in that case 18:58:05 OK 18:58:27 also to ivar-lazzaro’s point, lets include the part about the calls from the ML2 drivers to GBP also in the spec 18:58:33 SumitNaiksatam, rkukura, sure, I will check the gerrit review. 18:59:01 we have one minute left 18:59:07 there was one more topic on the agenda 18:59:18 but i think we will have to skip it for this meeting 18:59:28 #topic Open Discussion 18:59:43 mageshgv: you have been working on the floating IP support design and impl 18:59:53 hopefully you can provide an update in the next meeting 18:59:59 Deadline for conference session proposal for L-Summit is next Monday 19:00:01 meanwhile lets keeping it going on the emails 19:00:08 SumitNaiksatam: yes, sure 19:00:09 and please review 19:00:17 okay we are out of time 19:00:21 thanks all for joining 19:00:23 bye 19:00:28 bye 19:00:28 bye 19:00:31 that was quick 19:00:33 bye 19:00:35 bye 19:00:35 bye 19:00:37 #endmeeting