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