18:01:04 <SumitNaiksatam> #startmeeting networking_policy
18:01:05 <openstack> Meeting started Thu Feb 12 18:01:04 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:09 <openstack> The meeting name has been set to 'networking_policy'
18:01:31 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#Feb_12th.2C_2015
18:02:00 <SumitNaiksatam> #info Kilo-1 for GBP is Feb 16th
18:02:26 <banix> hi
18:02:34 <SumitNaiksatam> KrishnaK: banix: hi
18:02:43 <SumitNaiksatam> #topic Bugs
18:02:58 <KrishnaK> hi SumitNaiksatam, banix
18:03:09 <SumitNaiksatam> per last meeting, i have posted links to the k-1 bugs
18:03:31 <SumitNaiksatam> we still have quite a few pending (and some new ones are showing up)
18:03:54 <SumitNaiksatam> last week we took some time to discuss: #link https://bugs.launchpad.net/group-based-policy/+bug/1414139
18:03:54 <openstack> Launchpad bug 1414139 in Group Based Policy "RMD assumes implicit driver running" [Medium,New] - Assigned to Ivar Lazzaro (mmaleckk)
18:04:14 <SumitNaiksatam> nice, bot runs now ;-)
18:04:26 <SumitNaiksatam> i believe Ivar is not here
18:04:48 <SumitNaiksatam> i am not sure if he had a chance to make progress on this
18:05:12 <SumitNaiksatam> i know he was focussed on fixing some issues in the external connectivity model
18:05:29 <SumitNaiksatam> any other bugs that we want to discuss here? any blockers?
18:06:19 <SumitNaiksatam> rkukura: you were mentioning that you had some sqlalchemy issues?
18:06:25 <ivar-lazzaro> hi
18:06:28 <rkukura> SumitNaiksatam: https://bugs.launchpad.net/group-based-policy/+bug/1383947 is high and for k-1, but my comment recommends postponing until later
18:06:28 <openstack> Launchpad bug 1383947 in Group Based Policy "subnet mapping broken with overlapping ips" [High,Confirmed] - Assigned to Robert Kukura (rkukura)
18:06:57 <SumitNaiksatam> rkukura: yes, can you change the milestone to the relevant one?
18:07:01 <SumitNaiksatam> ivar-lazzaro: hi
18:07:03 <rkukura> See https://bugs.launchpad.net/group-based-policy/+bug/1383947/comments/3
18:07:12 <rkukura> SumitNaiksatam: OK
18:07:28 <SumitNaiksatam> ivar-lazzaro: we just went past the “"RMD assumes implicit driver running" bug
18:07:34 <SumitNaiksatam> ivar-lazzaro: anything to report on that?
18:07:55 <SumitNaiksatam> oops, seems to have lost him
18:08:37 <ivar-lazzaro> SumitNaiksatam: do'h
18:09:41 <SumitNaiksatam> ivar-lazzaro: were you able to see the backscroll?
18:10:07 <SumitNaiksatam> was just checking if you wanted to dicuss "RMD assumes implicit driver running" bug?
18:10:48 <ivar-lazzaro> SumitNaiksatam: I have no progress on that side, I was wondering if we should adopt the "validator" phase solution or if we should wait after the refactor instead
18:11:22 <SumitNaiksatam> ivar-lazzaro: can quickly summarize “validator phase” solution?
18:11:26 <ivar-lazzaro> SumitNaiksatam: of course if we plan on keeping the current ML2 architecture as is the order really doesn't matter
18:12:01 <SumitNaiksatam> ivar-lazzaro: i would say it depends on how critical this issue is
18:12:13 <SumitNaiksatam> currently its marked as medium
18:12:23 <SumitNaiksatam> if so we can potentially wait
18:12:56 <SumitNaiksatam> but if its actually higher priority, we should fix the issue before refactor (and bump up the priority of this bug)
18:13:19 <SumitNaiksatam> i dont anticipate the first phase of the refactor to do away with current ML2-like arch
18:13:59 <SumitNaiksatam> i think we will need more discussion on that, and its not preferable to hold up the other refactor effort for that discussion
18:14:08 <rkukura> Is there a requirement to run without IPD?
18:14:52 <rkukura> I mean a short-term requirement. I agree we shouid fix this eventually.
18:14:56 <SumitNaiksatam> rkukura: i believe the suggestion is that the RMD should be self contained
18:15:17 <SumitNaiksatam> rkukura: in that it doesnt assume resource dependencies exist
18:15:50 <SumitNaiksatam> rkukura: i am not aware of the immediate short term requirement, perhaps ivar-lazzaro has run into an issue on account of this?
18:16:52 <s3wong> sorry, late
18:16:56 <SumitNaiksatam> not sure if ivar-lazzaro is still around or dropped off
18:17:00 <SumitNaiksatam> s3wong: hi, np
18:17:29 <SumitNaiksatam> as I mentioned earlier we are also catching some issues during the external connectivity testing
18:17:50 <SumitNaiksatam> the issues have not been filed yet, but will do so soon
18:18:14 <SumitNaiksatam> some of them might be backports (fyi - in case you are planning to use the external connectivity model)
18:18:33 <SumitNaiksatam> mageshgv: any service-chain related bugs you need to discuss here?
18:19:09 <SumitNaiksatam> oh, i find a few and have filed them, and have a fix for some of them
18:19:25 <mageshgv> SumitNaiksatam: No. I havent made much progress on the current bugs, saw a few new ones and working on those at present
18:19:33 <SumitNaiksatam> i was having issues with the one-convergence tests
18:19:38 <SumitNaiksatam> mageshgv: i will sync with you offline
18:19:54 <mageshgv> SumitNaiksatam: Fine, we can discuss offline
18:20:00 <SumitNaiksatam> mageshgv: thanks
18:20:15 <ivar-lazzaro> we can add a pre-processing phase (or validator) *before* the DB transaction starts
18:20:15 <SumitNaiksatam> just a reminder folks, K-1 is feb-16th
18:20:15 <ivar-lazzaro> therefore before the pre-commit
18:20:16 <ivar-lazzaro> in which the implicit mapping can do the object creation
18:20:18 <ivar-lazzaro> so that the pre-commit phase will already be seeing the full chain of objects produced by a given call
18:20:18 <ivar-lazzaro> and can validate properly
18:20:18 <ivar-lazzaro> The issue has a workaround (always run the Implicit Policy Driver)
18:20:18 <ivar-lazzaro> I think that's fair
18:20:45 <SumitNaiksatam> ivar-lazzaro: okay
18:21:17 <ivar-lazzaro> ok I got back after a pretty bad connection time :)
18:21:39 <SumitNaiksatam> regarding the deadline - if an issue is assigned to you and is targeted for k-1, please respond to that launchpad with an update
18:21:58 <SumitNaiksatam> KrishnaK: thanks for fixing the bug in your plate, it it merged now?
18:22:16 <KrishnaK> SumitNaiksatam: Not yet merged. Need review of this bug: https://review.openstack.org/#/c/153900/
18:23:22 <SumitNaiksatam> KrishnaK: hi cores, can you please take a look at ^^^ #link https://review.openstack.org/#/c/153900/
18:23:30 <SumitNaiksatam> pretty straightforward
18:23:57 <rkukura> I’ll review that today
18:24:05 <SumitNaiksatam> KrishnaK: you had another one in your plate i believe?
18:24:15 <KrishnaK> rkukura. Thx.
18:24:32 <KrishnaK> SumitNaiksatam: yes. I'll look at other bug soon.
18:24:38 <SumitNaiksatam> KrishnaK: thanks
18:24:55 <SumitNaiksatam> in general, if anyone has a pending review and is not getting reviewer attention please yell! :-)
18:25:00 <SumitNaiksatam> or get in touch with me
18:25:09 <SumitNaiksatam> we also have the #openstack-gbp channel
18:25:23 <SumitNaiksatam> and a bunch of the cores are there on that channel
18:25:34 <KrishnaK> SumitNaiksatam: Thx for that info.
18:25:40 <SumitNaiksatam> (i would request all cores to log in whenever convenient)
18:26:03 <SumitNaiksatam> KrishnaK: not specifically target at you, i know you have been trying your best to get attention :-)
18:26:16 <SumitNaiksatam> okay if nothing else on the pending bugs, lets move on
18:26:36 <SumitNaiksatam> #topic “Re-factor Group Based Policy with Neutron RESTful APIs”
18:26:45 <SumitNaiksatam> #link https://review.openstack.org/#/c/153126
18:26:51 <SumitNaiksatam> i believe Yi  is here
18:26:56 <Yi> yes, I am here
18:27:18 <Yi> I was able to use the RESTful API to create network
18:27:26 <SumitNaiksatam> i responded to the spec yesterday (had some very minor comments, mostly in response to Yi’s offline questions)
18:27:35 <SumitNaiksatam> Yi: thats nice progress!
18:27:46 <SumitNaiksatam> anyone else got a chance to look at the above spec
18:28:04 <SumitNaiksatam> its really pretty small, so i would appreciate if cores can take a look at it at the earliest
18:28:18 <SumitNaiksatam> last week we had an action to provide immediate review comments on this one
18:28:47 <SumitNaiksatam> i believe Yi and yapeng are kind of waiting on a “thumbs-up" for this
18:28:56 <ivar-lazzaro> will do today
18:29:12 <SumitNaiksatam> ivar-lazzaro: thanks!
18:29:19 <Yi> we appreciate it!
18:29:25 <SumitNaiksatam> Yi: its good you have the implementation going
18:29:38 <Yi> That's what I was trying to do.
18:29:45 <SumitNaiksatam> Yi: please dont hesitate to bug the team if you run into any issues
18:29:54 <Yi> certainly
18:30:12 <Yi> and I need to poll your opinion actually
18:30:29 <SumitNaiksatam> as i mentioned before #openstack-gbp can also be a good resource to get immediate attention (and emails will also work)
18:30:39 <SumitNaiksatam> Yi: yes please
18:30:43 <Yi> regarding the location of the module
18:30:52 <SumitNaiksatam> ah okay
18:31:03 <SumitNaiksatam> my suggestion was to use the way nova does it
18:31:24 <Yi> which would be gbpservice/network/neutronv2
18:31:32 <SumitNaiksatam> yeah in our case
18:31:47 <SumitNaiksatam> if others have differing opinion please comment on the review at the earliest
18:31:53 <SumitNaiksatam> and/or here
18:32:55 <SumitNaiksatam> okay silence is golden - Yi so you can use this module path for now :-)
18:33:06 <SumitNaiksatam> i dont hear objections
18:33:07 <Yi> good :-)
18:33:19 <SumitNaiksatam> Yi: any other issues you wanted to discuss?
18:33:32 <SumitNaiksatam> i also mentioned about the neutron client version
18:33:39 <Yi> ?
18:33:45 <SumitNaiksatam> in the review
18:33:56 <Yi> I will check it out
18:33:56 <SumitNaiksatam> our other gbp projects are using 2.3.9
18:34:07 <SumitNaiksatam> whereas the latest in 2.3.10
18:34:25 <SumitNaiksatam> until we move the other projects to 2.3.10, we should use 2.3.9 here as well
18:34:36 <SumitNaiksatam> the move to 2.3.10 has been targeted for k-2
18:34:44 <SumitNaiksatam> so go with 2.3.9
18:34:54 <SumitNaiksatam> i believe you will have to add this to the requirements file
18:34:57 <Yi> make sense
18:35:04 <Yi> will do
18:35:08 <SumitNaiksatam> Yi: thanks
18:35:36 <SumitNaiksatam> Yi: anything else on this?
18:35:42 <SumitNaiksatam> yapeng not around today?
18:35:47 <Yi> One thing I do notice is we have dependency on plugin context
18:36:05 <Yi> yapeng is in China this week, I believe
18:36:10 <SumitNaiksatam> Yi: ah
18:36:22 <SumitNaiksatam> Yi: what about the plugin context, is that creating an issue?
18:36:50 <Yi> not an issue right now, as I can use plugin context directly
18:37:19 <Yi> but I'd assume later when we have gbp independent, we should not reply on the plugin context?
18:37:49 <SumitNaiksatam> Yi: i am not fully understanding, but lets take that offline
18:37:50 <Yi> i.e., to keep the auth_token and other attributes in the context instead of plugin context?
18:38:08 <Yi> sure, let's discuss it offline
18:38:17 <SumitNaiksatam> rkukura: can i request you to provide Yi some guidance on this if required?
18:38:23 <rkukura> Yi: I’d think we’d replace the neutron plugin context with something similar. Sure.
18:38:40 <SumitNaiksatam> rkukura: thanks!
18:39:08 <Yi> rkukura: I think that will be fine in the future
18:39:39 <SumitNaiksatam> Yi: thanks for the update
18:39:43 <SumitNaiksatam> want to give some time to the next topic
18:39:46 <Yi> yw
18:39:58 <SumitNaiksatam> #topic “Floating IP Support”
18:40:03 <SumitNaiksatam> mageshgv: over to you
18:40:18 <SumitNaiksatam> i believe you have made some progress?
18:40:51 <mageshgv> SumitNaiksatam: Yes, I am stuck somewhere now though. Will expand on this design
18:41:26 <mageshgv> From an api perspective, the idea was to use Network service policy with type ip_pool and value external_subnet to indicate all PTs should get a FIP.
18:41:26 <SumitNaiksatam> mageshgv: okay :-)
18:41:54 <mageshgv> Another alternative user friendly api option is to extend PTG with a parameter to indicate that all PTs on this PTG should get a floating IP associated.
18:41:56 <SumitNaiksatam> mageshgv: yes, as i recalled from prior discussions in the original GBP spec
18:42:16 <SumitNaiksatam> i meant yes for the earlie alternative
18:42:17 <rkukura> mageshgv: Can we just infer based on the policies whether a PTG needs FIPs?
18:42:36 <SumitNaiksatam> rkukura: that was idea in encoding that in the Network Service Policy
18:42:36 <rkukura> I don’t think FIPs should be part of the “intent”.
18:43:02 <mageshgv> rkukura: right, that is why we were thinking to use Network Service Policy
18:43:05 <SumitNaiksatam> rkukura: i think i agree with that
18:43:22 <rkukura> I’m not sure how we represent external networks, but if there is a policy allowing incoming connections, a FIP is needed. If not, it isn’t.
18:43:31 <SumitNaiksatam> mageshgv: perhaps the alternatives should be captured in the design (in the alternative section)
18:43:54 <mageshgv> SumitNaiksatam: okay, will add that too
18:43:59 <rkukura> “external” here could also mean a different L3P from the same tenant or a different tenant, as well as outside-the-cloud
18:44:24 <ivar-lazzaro> mageshgv, SumitNaiksatam, rkukura: what about the nat-pool object?
18:44:51 <ivar-lazzaro> which already exists from the external connectivity blueprint
18:45:07 <rkukura> ivar-lazzaro: I need to re-read that BP (and code)
18:46:07 <SumitNaiksatam> mageshgv: perhaps good to post the spec at the earliest
18:46:18 <ivar-lazzaro> #link https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/external-connectivity.rst
18:46:24 <SumitNaiksatam> so that people can relate to different parts of the model
18:46:52 <ivar-lazzaro> the idea of the NAT pool was to provide a pool of FIPs that all the PT from a given external-segment would be assigned with
18:46:53 <mageshgv> ivar-lazzaro: you are correct, we have to use the nat pool to achieve this, but I havent modelled a proper relation with this nat pool yet
18:47:42 <ivar-lazzaro> mageshgv: keep in mind that the nat pool is not used today by any driver. So feel free to remove/change it if you think of a better solution
18:47:42 <SumitNaiksatam> ivar-lazzaro: my understanding is that the trigger comes from the Network Service Policy (whether to configure FIP or not)
18:47:47 <rkukura> ivar-lazzaro: I also agree a NAT pool is needed by the PTG, but just was thinking whether to allocate a FIP could be inferred.
18:48:52 <ivar-lazzaro> SumitNaiksatam: why from NSP? This should be a property of the L3Policy IMHO
18:48:52 <mageshgv> rkukura: We need some way of way of expressing this floating ip policy and also like it to a nat pool
18:48:59 <SumitNaiksatam> there are two steps, first whether to use the FIP or not (which can be characterized as the “intent”), and the second is where to pull the FIPs from, if used
18:49:06 <ivar-lazzaro> SumitNaiksatam: (therefore a property of the external segment)
18:49:46 <rkukura> SumitNaiksatam: makes sense, ivar-lazzaro: L3P seems to make sense
18:50:09 <SumitNaiksatam> ivar-lazzaro: because, FIP is achieved using NAT, which can be thought of as a service
18:50:25 <ivar-lazzaro> Originally the simple idea was: Any PT created on a EPG which external connectivity (see external-segment) will be granted a FIP from the nat pool
18:50:49 <SumitNaiksatam> and allows the choice of explicit versus implicit NAT services to achieve it
18:51:15 <ivar-lazzaro> SumitNaiksatam: FIP could just be a routable address, not necessarily implemented using NAT
18:51:18 <SumitNaiksatam> ivar-lazzaro: why should that be the case?
18:51:21 <ivar-lazzaro> SumitNaiksatam:  (see IPv6)
18:51:41 <SumitNaiksatam> ivar-lazzaro: yeah, but it could also be a NAT, which it commonly is in IPv4
18:51:58 <Yi> ivar-lazzaro: I agree with rkukura, NAT pool and FIP pool may not necessarily by related
18:52:06 <ivar-lazzaro> SumitNaiksatam: true, but we have to catch the intent
18:52:15 <SumitNaiksatam> ivar-lazzaro: external connectivity is for going from the inside to the outside
18:52:16 <mageshgv> ivar-lazzaro: If I understand it correctly, in the current model, external segment by itself represents a PTG. Is that not the case ?
18:52:21 <ivar-lazzaro> we don't really care wether it's a service or not
18:52:26 <SumitNaiksatam> so does not necessarily need a FIP
18:52:29 <rkukura> Ideally, intent would not be different for IPv4 vs. IPv6
18:52:36 <SumitNaiksatam> ivar-lazzaro: it needs a NAT pool, not a FIP
18:52:55 <SumitNaiksatam> ivar-lazzaro: a FIP can also be assigned from that pool
18:53:04 <ivar-lazzaro> mageshgv: no, external policy is a PTG. External Segment is an extension of the L3P basically
18:53:06 <SumitNaiksatam> rkukura: true
18:53:21 <ivar-lazzaro> rkukura: exactly
18:53:37 <mageshgv> ivar-lazzaro: my bad got mixed up with the two resources
18:53:39 <SumitNaiksatam> rkukura: hence the NSP model which tries to generalize that
18:53:42 <ivar-lazzaro> maybe nat-pool is not the best choice in term of naming
18:53:58 <ivar-lazzaro> mageshgv: ES describes how a L3P can reach the external world
18:54:35 <SumitNaiksatam> okay, we have 6 mins remaining, and at least one more item to cover
18:54:46 <SumitNaiksatam> i belive we need to see the spec and comment in the review
18:55:00 <SumitNaiksatam> mageshgv: what is your estimate for posting the spec
18:55:02 <SumitNaiksatam> ?
18:55:15 <mageshgv> I should be able to post it by this weekend
18:55:26 <SumitNaiksatam> mageshgv: ok thanks, the earlier the better :-)
18:55:38 <mageshgv> SumitNaiksatam: sure
18:55:39 <ivar-lazzaro> The point is to understand if we want to assign FIPs per L3Policy or per PTG
18:55:45 <SumitNaiksatam> since this is currently targeted for K-1 :-)
18:55:53 <ivar-lazzaro> we could also use labels eventually for a greater granularity
18:56:28 <SumitNaiksatam> mageshgv: thanks for the update
18:56:39 <SumitNaiksatam> #topic Taskflow investigation
18:56:50 <SumitNaiksatam> rkukura: over to you
18:57:09 <rkukura> SumitNaiksatam: I started looking at https://review.openstack.org/154333, which the start of a PoC for incorporating TaskFlow into ML2.
18:57:34 <rkukura> But it needs a ton more work to really make any sense.
18:57:49 <SumitNaiksatam> rkukura: okay, so this patch is not complete?
18:57:51 <rkukura> I’d like to also look at how other projects are using TaskFlow.
18:58:05 <rkukura> SumitNaiksatam: Its a WiP of a PoC
18:58:20 <SumitNaiksatam> rkukura: okay
18:58:37 <SumitNaiksatam> rkukura: so is taskflow targeted in Neutron for Kilo?
18:58:45 <rkukura> I’d like to see how we really should combine the concepts of driver and task
18:59:10 <rkukura> SumitNaiksatam: No, the ML2 TaskFlow is investigation going into Liberty planning
18:59:37 <SumitNaiksatam> rkukura: ah ok
18:59:38 <rkukura> No decisions have been made about it. Just working towards a BP.
18:59:50 <rkukura> That’s all I have right now, but will continue.
19:00:13 <SumitNaiksatam> so perhaps that tells that the scope is large
19:00:21 <SumitNaiksatam> rkukura: thanks for that update
19:00:26 <SumitNaiksatam> #topic Open Discussion
19:00:31 <SumitNaiksatam> we are at the hour
19:00:39 <SumitNaiksatam> any parting comments, or anything that we missed?
19:00:53 <SumitNaiksatam> else over to #openstack-gbp
19:00:54 <rkukura> One note - The RDO GBP instructions at https://openstack.redhat.com/Neutron_GBP have been updated.
19:01:01 <SumitNaiksatam> rkukura: awesome!
19:01:08 <SumitNaiksatam> we skipped the packaging standing item
19:01:17 <SumitNaiksatam> all right, thanks everyone
19:01:21 <SumitNaiksatam> bye
19:01:33 <SumitNaiksatam> #endmeeting