18:02:42 <SumitNaiksatam> #startmeeting networking_policy
18:02:43 <openstack> Meeting started Thu Jun 26 18:02:42 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:46 <openstack> The meeting name has been set to 'networking_policy'
18:02:54 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:03:19 <SumitNaiksatam> #topic API/Resource Model patches
18:03:45 <SumitNaiksatam> so as in the past week, there was decent amount of review acitvity on these patches
18:04:15 <SumitNaiksatam> btw, for the links to all the patches see: #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#June_26.2C_19.2C_12.2C_2014
18:04:23 <SumitNaiksatam> had been planning to put the above in a wiki page
18:04:45 <SumitNaiksatam> i still need to respond to HenryG and enikanorov’s comments on the DB patch, but nothing major there
18:05:07 <SumitNaiksatam> other than that, the API patch for the classifier, actions and rules was also posted:
18:05:18 <SumitNaiksatam> #link https://review.openstack.org/#/c/101816
18:05:29 <rkukura> SumitNaiksatam: Should I wait for you to update the gp-*-1 patches before rebasing mine?
18:05:58 <SumitNaiksatam> rkukura: if you can that will be good, i will try to do it asap after the meeting (my plan was to have done that yesterday itself)
18:06:07 <SumitNaiksatam> rkukura: i will drop you a note as soon as i am done
18:06:17 <rkukura> OK, want to minimize churn, so I’ll wait
18:06:23 <SumitNaiksatam> rkukura: ok cool
18:06:40 <SumitNaiksatam> thats pretty much my update, open to questions/comments
18:07:36 <SumitNaiksatam> if no questions then we can move to the mapping update
18:07:52 <SumitNaiksatam> #topic Mapping api/driver/data path patches
18:08:03 <SumitNaiksatam> rkukura: over to you
18:08:28 <rkukura> I’m on PTO yesterday through next Wednesday (7/2), but am trying to finish up the two driver patches
18:08:50 <SumitNaiksatam> rkukura: i updated the agenda with the links to the patches
18:08:54 <rkukura> I’ll rebase the exisitng patches on SumitNaiksatam’s upcoming update, and post those today
18:09:07 <LouisF> rkukura: when an EPG is created, does a network and subnet also get created?
18:09:11 <rkukura> I hope to have the implicit policy driver patch posted today
18:09:23 <SumitNaiksatam> rkukura: nice!
18:09:45 <rkukura> LouisF: The resource mapping driver will take care of creating the subnet for the EPG
18:10:14 <rkukura> The implicit policy driver will create the L2P for the EPG if one isn’t passed in explciitly
18:10:19 <s3wong> rkukura: these patches will be using the python-clients?
18:10:25 <LouisF> rkukura: and network also?
18:10:31 <rkukura> and the resource mapping driver will create the network for the L2P
18:10:50 <rkukura> The plan is for the resource mapping driver to use the python client for non-GP APIs
18:10:56 <SumitNaiksatam> LouisF: L2P maps to the network
18:11:10 <rkukura> The implicit policy driver is currently calling the plugin directly
18:12:09 <LouisF> rkukura: when will use of python client be added?
18:12:10 <rkukura> It turns out the PoC code in these drivers needs significant work to be ready to review and merge, like deletion of resources, unit tests, etc.
18:12:24 <SumitNaiksatam> s3wong: i believe you will need to use the python client for the security group mapping
18:12:35 <s3wong> SumitNaiksatam: yes - hence the question to rkukura :-)
18:12:39 <rkukura> LouisF: That will be added to the resource mapping driver before its posted for review, hopefully in the next couple days
18:12:58 <SumitNaiksatam> s3wong: i realized that, hence reiterating :-)
18:12:59 <LouisF> rkukura: will look out for it
18:13:05 <rkukura> OK
18:13:40 <rkukura> LouisF: Do you see any problem with calling the GP plugin directly in the implicit policy driver?
18:14:02 <LouisF> rkukura: no
18:14:04 <SumitNaiksatam> rkukura: perhaps having a very high level block diagram with the different pieces (implicit driver, mapping driver, etc) might help in review
18:14:14 <LouisF> +1
18:14:15 <rkukura> OK, great
18:14:18 <SumitNaiksatam> rkukura: and posting on our GP wiki
18:14:41 <SumitNaiksatam> rkukura: will you have time at all for this, or we can see if someone else can put it there
18:14:51 <rkukura> I’ll see if I can come up with something, but I’m on PTO, so I can’t get away with too much time on work
18:15:04 <s3wong> rkukura: why not :-) ?
18:15:12 <rkukura> Someone else doing the diagram would be great
18:15:43 <rkukura> working while snorkeling or ziplining would not go well
18:15:43 <SumitNaiksatam> #action SumitNaiksatam to put block diagram for mapping driver (or delegate to someone else :-P)
18:16:18 <rkukura> while flying is fine
18:16:26 * SumitNaiksatam rkukura has planned an adventorous vacation! :-)
18:17:00 <SumitNaiksatam> rkukura: any other questions for rkukura?
18:17:03 <rkukura> SumitNaiksatam: this is what we’ve been waiting for since the twins were born 16 years ago
18:17:15 <SumitNaiksatam> rkukura: you absolutely deserve it!
18:17:20 <LouisF> enjoy
18:17:38 <rkukura> thanks
18:17:50 <rkukura> any other mapping questions
18:17:52 <rkukura> ?
18:18:26 <LouisF> mapping of policy rules to security groups?
18:18:33 <SumitNaiksatam> s3wong: perhaps you want to give a quick update on the security groups mapping (to the extent that you have thought about it)?
18:18:41 <SumitNaiksatam> LouisF: ah LouisF right on cue :-)
18:18:56 <LouisF> working on my timing...
18:19:11 <s3wong> SumitNaiksatam: still reading rkukura 's code to understand the structure of the current mapping driver
18:19:27 <SumitNaiksatam> s3wong: sure
18:19:40 <SumitNaiksatam> s3wong: whats the high level plan?
18:20:00 <SumitNaiksatam> s3wong: for the benefit of everyone here
18:20:00 <rkukura> s3wong: I’ll probably be adding some tables in the driver, and maybe we could store the SG_id there
18:20:35 <rkukura> s3wong: Assuming we don’t want to expose the SG in the API like we do for the port, network, subnet, and router
18:21:26 <SumitNaiksatam> rkukura: probably not
18:21:27 <s3wong> rkukura: yes, we certainly don't want to make SG visible in the API
18:22:09 <rkukura> s3wong, SumitNaiksatam: Is the rationale that we need complete control of the SG, and can’t let users muck with it?
18:22:27 <SumitNaiksatam> rkukura: that has been the thinking until this point
18:22:31 <s3wong> rkukura: we should, right?
18:23:00 <rkukura> I agree we need complete control, since SG rule ordering is important, so we should not expose it in the API
18:23:20 <SumitNaiksatam> rkukura: i think differnt backends can enforce the contract rules in different ways, so in that sense SG mapping is an implementation detail here
18:23:48 <rkukura> right, even if a backend exposes networks, subnets, and ports, it may not be using SGs for policy rendering
18:23:55 <SumitNaiksatam> rkukura: yeah
18:24:08 <rkukura> seems we all agree to keep the SGs internal to the mapping driver, right?
18:24:19 <s3wong> rkukura: yes
18:24:28 <SumitNaiksatam> rkukura: that said, to your point, i believe if the user really wants to muck around with the mapped SGs he would still be able to do it, right?
18:24:45 <SumitNaiksatam> rkukura: i mean the mapped SGs would be visible to him
18:25:03 <rkukura> Unless we create them with a different tenant, the user can discover and update/delete them
18:25:15 <SumitNaiksatam> rkukura: ok, so s3wong something to think about
18:25:22 <LouisF> will this SG that is "owned" by GBP appear in the SG list?
18:25:47 <SumitNaiksatam> LouisF: we hadnt planned a separate “GBP” tenant until this point
18:26:01 <s3wong> rkukura: can a SG created by a different tenant be apply to traffic in the other tenant?
18:26:08 <rkukura> I think we should stick with using the client’s tenant for now, but keep the option open to change that later. But SGs may need to be the same tenant as the port - not sure
18:26:15 <SumitNaiksatam> rkukura: +1
18:27:02 <SumitNaiksatam> we can perhaps evolve with a new role, like what is being propose with the “adv services” role
18:27:26 <SumitNaiksatam> #link https://review.openstack.org/101281
18:27:49 <s3wong> SumitNaiksatam: the "adv services" role gets admin previleges, right?
18:27:52 <SumitNaiksatam> the above was FYI for the advsvs role
18:27:59 <SumitNaiksatam> s3wong: yes
18:28:07 <SumitNaiksatam> on a slightly different note
18:28:12 <SumitNaiksatam> regarding the stacking of patches
18:28:27 <SumitNaiksatam> may be i will change the topic
18:28:53 <SumitNaiksatam> before that any other questions for s3wong on SG mapping (he just started looking at this, so be kind to him)
18:29:33 <s3wong> so kind :-)
18:29:36 <SumitNaiksatam> s3wong: is there anything more that you need to sort out?
18:30:11 <SumitNaiksatam> ok moving on
18:30:13 <s3wong> SumitNaiksatam: just generally understand what there currently, and how/when to invoke python-clients
18:30:21 <SumitNaiksatam> s3wong: ok
18:30:31 <s3wong> SumitNaiksatam: so need more investigation before I can ask proper questions :-)
18:30:31 <SumitNaiksatam> #topic Stacking of patches
18:30:36 <SumitNaiksatam> s3wong: ok
18:31:10 <SumitNaiksatam> so initially we had the plan to make progress in “bread” and “depth” fashion wih regards to stacking the patches
18:31:22 <s3wong> breath?
18:31:26 <SumitNaiksatam> where depth goes from API to the driver/data path level
18:31:46 <SumitNaiksatam> and breadth traverses the resources in the GP model
18:31:52 <SumitNaiksatam> s3wong: ^^^
18:32:03 <s3wong> :-)
18:32:12 <SumitNaiksatam> to that end we have the depth series with EP, EPG, L2/3P
18:32:33 <SumitNaiksatam> i started the breadth series with the classifier, action, rules
18:33:32 * SumitNaiksatam thinks needs rkukura’s help for 3 lettter acronymys for classifier, actions, rules
18:33:58 <rkukura> CARs
18:34:04 <SumitNaiksatam> so the classifier, … API patch is currently based of the GP-plugin-1 patch
18:34:07 <SumitNaiksatam> rkukura: :-)
18:34:29 <SumitNaiksatam> but when you pull that GP-API-2 patch, you dont get any of the mapping stuff
18:34:41 <SumitNaiksatam> or the anticipated driver stuff
18:34:53 <SumitNaiksatam> and the SG mapping would need that
18:35:13 <SumitNaiksatam> so the question is, should we have one linear series of patches?
18:35:35 <SumitNaiksatam> i guess its unavoidable, but it will be one long series!
18:35:51 <rkukura> I think we’ll eventually need to make it linear, but short term can have forks
18:36:18 <rkukura> hopefully we can get the gp-*-1 series merged before too long
18:36:55 <Cathy_> SumitNaiksatam: a side question on this. Is there any sync-up on the classifier between GBP and Traffic Steering when they are both used for support of service chaining?
18:37:05 <rkukura> for now, both gpm-*-1 and gp*-2 are based off gp-api-1, right
18:37:06 <rkukura> ?
18:37:26 <SumitNaiksatam> rkukura: that was the hope that we would get it merged sooner
18:37:54 <SumitNaiksatam> rkukura: yes, GP-API-2 is based off GP-Plugin-1
18:38:05 <rkukura> that’s what I meant
18:38:10 <SumitNaiksatam> rkukura: yeah
18:38:17 <SumitNaiksatam> Cathy_: thanks for bringing that up
18:38:29 <rkukura> so we could rebase gp-*-2 off of gpm-plugin-1 at any point
18:38:59 <SumitNaiksatam> rkukura: yeah, actuall i would think GPM-Driver-*?
18:39:14 <rkukura> then later rebase them off gpm-rmd-1
18:39:59 <SumitNaiksatam> rkukura: RMD?
18:40:01 <rkukura> gp-api-1, gp-db-1, gp-plugin-1, gpm-api-1, gpm-db-1, gpm-plugin-1, gpm-ipd-1, gpm-rmd-1, gp-api-2, …?
18:40:08 <rkukura> resource mapping driver
18:40:26 <rkukura> gpm-ipd-1 is implicit policy driver
18:40:35 <SumitNaiksatam> rkukura: yeah, got that! :-)
18:40:54 <Cathy_> SumitNaiksatam: sure. If  you need any help on the part related to service chaining, please let me know.
18:40:57 <SumitNaiksatam> rkukura: acronym czar! :-)
18:41:06 <SumitNaiksatam> Cathy_: thats the next topic
18:41:17 <SumitNaiksatam> #topic Services’ integration
18:42:03 <SumitNaiksatam> i was hoping mandeep would be around to discuss the service chaining
18:42:12 <SumitNaiksatam> is cgoncalves around?
18:42:14 <Cathy_> I hope so
18:42:34 <SumitNaiksatam> i dont see mandeep in this channel though
18:42:45 <s3wong> SumitNaiksatam: too late at night for folks in Europe
18:42:53 <s3wong> (not mandeep)
18:43:32 <SumitNaiksatam> yeah, so both cgoncalves and mandeep are not around
18:44:11 <SumitNaiksatam> Cathy_: the way i understand it, the service chaining bp was written to be independent of the implementation menchanism
18:44:41 <SumitNaiksatam> Cathy_: which means that the TS is not strictly required for implementing the service chaining
18:45:02 <SumitNaiksatam> Cathy_: also the intial focus of the service chaining bp is on the services which are exposed in neutron
18:45:37 <Cathy_> SumitNaiksatam: Yes, I understand, but when it is used for service chaining, the API should not cause any conflict between the API in GBP or the other way around
18:45:42 <SumitNaiksatam> Cathy_: in the GP reference implementation, we will point to a service or a service chain UUID in the redirect action
18:45:58 <SumitNaiksatam> Cathy_: that is a good point
18:47:16 <SumitNaiksatam> Cathy_: the port-chaining API in the TS bp is useful for chaining services which are realized in VMs and which Neutron is not aware of
18:47:38 <SumitNaiksatam> i hope we still have everyone here after the split
18:47:53 <LouisF> here
18:47:54 <Cathy_> SumitNaiksatam: could you clarify what is meant by point to a "service" in the redirect?
18:48:02 <s3wong_> I was kicked out
18:48:05 <banix> y
18:48:07 <rkukura> I’m here
18:48:32 <s3wong_> topic still intact, or maybe that's just my client
18:49:03 <Cathy_> SumitNaiksatam: does that mean user can specify a sequence of service instance IDs after the "redirect"?
18:49:03 <SumitNaiksatam> Cathy_: is you question whethe we will allow the port-chain to be used in the redirect action?
18:49:31 <Cathy_> SumitNaiksatam: not really
18:49:47 <s3wong_> Cathy_: we don't. Just ONE UUID for now
18:50:16 <SumitNaiksatam> *whether
18:50:25 <Cathy_> s3wong_: thanks. How about in the future? since SumitNaiksatam mentions "service" for redirect too?
18:51:05 <s3wong_> Cathy_: for now we are thinking that if you want a chain, the chain would be created by service chaining APIs
18:51:31 <s3wong_> since it is highly unlikely that the user of GBP APIs (app-owners) would want to chain his own service chains
18:52:18 <SumitNaiksatam> s3wong banix Cathy_ LouisF: still there?
18:52:24 <Cathy_> I think it is not chain his own service chain. It is redirect a flow to a service chain which consists of a sequence of service function instances, right?
18:52:24 <s3wong_> SumitNaiksatam: hi
18:52:25 <LouisF> yes
18:52:28 <banix> yes
18:53:00 <s3wong_> Cathy_: in that case, can the service functions be chained by the service chaining APIs?
18:53:20 <Cathy_> s3wong_: not sure what you meant by that?
18:53:48 <Cathy_> s3wong_: are you taking about the service chaining API in advanced service BP?
18:54:05 <s3wong_> Cathy_: yes
18:54:12 <Cathy_> here is my thought
18:54:57 <SumitNaiksatam> are we all back?
18:55:01 <Cathy_> The service chaining API can specify the sequence of service function instances which is identified by a unique chain-ID and this chain-ID can be used in GBP for the "redirect"
18:55:06 <LouisF> Cathy_: https://review.openstack.org/#/c/93524
18:55:32 <s3wong_> Cathy_: yes
18:55:42 <Cathy_> good, so now the issues is
18:55:57 <SumitNaiksatam> s3wong banix rkukura songole Cathy_ LouisF: there?
18:56:05 <Cathy_> we only need one place to specify the classifier
18:56:06 <s3wong_> SumitNaiksatam: hello?
18:56:19 <Cathy_> SumitNaiksatam: yes I am here.
18:56:20 <rkukura> yes
18:56:25 <banix> SumitNaiksatam: been here all along :)
18:56:33 <LouisF> SumitNaiksatam: here
18:56:43 <s3wong_> my nic has changed though, from s3wong -> s3wong_
18:56:43 <SumitNaiksatam> oh i think i was on the other side of the split
18:57:00 <SumitNaiksatam> i did not see any of the conversation until now
18:57:11 <s3wong> yes, back to s3wong instead s3wong_ :-)
18:57:18 <Cathy_> s3wong_: but based on existing traffic steeing API and the GBP API, they are two places to specify the classiffier which can cause inconsistency.
18:57:43 <s3wong> Cathy_: so the classifier in GBP is used to apply policy
18:58:12 <Cathy_> s3wong: yes, but the policy consists of the redirect and chain-ID
18:58:26 <Cathy_> and classifier
18:58:41 <s3wong> Cathy_: the classifier in policy-rule does NOT need to be the same as TS'
18:58:50 <Cathy_> and the chain-ID also carries over the classifier designed in the TS
18:58:52 <SumitNaiksatam> Cathy_: lets not confuse the classifier in the TS with GBP
18:59:17 <SumitNaiksatam> Cathy_: right now the thinking is very simple, the GBP has a redirect action
18:59:29 <SumitNaiksatam> Cathy_: that redirect action has a value field
18:59:38 <s3wong> Cathy_: in fact, the TS' classifier is way more specific
18:59:38 <SumitNaiksatam> Cathy_: that value field takes a UUID
18:59:48 <s3wong> Cathy_: it has a src-ip and dst-ip fields to them
19:00:01 <SumitNaiksatam> Cathy_: that UUID can either be a Neutron service (FWaaS, LBaaS, or VPNaaS)
19:00:07 <LouisF> Cathy_: the chaining BP https://review.openstack.org/#/c/93524 does not have as classifier
19:00:17 <SumitNaiksatam> Cathy_: or it can be a Service Chain UUID
19:00:33 <Cathy_> s3wong: if the classifiers are not the same which one identifies the flow that will go through the service chain and what is the other classifier used for? Maybe I miss something here.
19:00:34 <s3wong> Cathy_: so what I can see possible, in the future - is that the mapping driver for 'redirect' COULD potentially use the TS python-clients to steer traffic to a service
19:00:46 <SumitNaiksatam> Cathy_: where service chain UUID is as per the spec #link https://review.openstack.org/#/c/93524
19:00:52 <banix> Cathy_: even if a GBP implementation uses TS then it will set the classifier appropriately
19:01:19 <Cathy_> LouisF: we are talking about TS API, not service chaining API
19:01:58 <s3wong> Cathy_: in the case of GBP mapping driver using TS, the TS parameters will be set up by GBP mapping driver to redirect traffic to a service (as specified by the UUID)
19:02:14 <banix> have to run unfortunately… see you all later
19:02:43 <SumitNaiksatam> banix: thanks for the reminder
19:02:48 <SumitNaiksatam> we are 2 mins over
19:02:57 <s3wong> Cathy_: IF the UUID specified happens to be a service chain - which also happens to use TS APIs (chains can use TS APIs too), then the chain's usage of the TS classifier is indpendent of how even the mapping driver is using the classifier
19:03:26 <s3wong> banix: have fun!
19:03:30 <Cathy_> s3wong: I will talk  with you off line. thanks
19:03:52 <Cathy_> SumitNaiksatam: thanks for discussing this.
19:04:15 <SumitNaiksatam> Cathy_: just pinged you on IM as well
19:04:23 <SumitNaiksatam> Cathy_: we can discuss this further offline
19:04:28 <Cathy_> SumitNaiksatam: sure
19:04:34 <Cathy_> SumitNaiksatam: how to reach you?
19:04:51 <SumitNaiksatam> Cathy_: check your IRC chat :-)
19:05:03 <SumitNaiksatam> Cathy_: i just pinged you
19:05:13 <SumitNaiksatam> is songole still here?
19:05:48 <SumitNaiksatam> #topic CLI and client
19:06:09 <SumitNaiksatam> wanted to get a quick update from songole since hemanthravi is away
19:06:27 <SumitNaiksatam> talked to songole and he will be updating the CLI/Client patch at the earliest
19:06:35 <SumitNaiksatam> to sync with GP-API-1
19:07:36 <SumitNaiksatam> #topic open discussion
19:07:39 <SumitNaiksatam> anytning else?
19:07:47 <SumitNaiksatam> not sure who else is still in the meeting
19:08:17 <SumitNaiksatam> ok lets wrap it up
19:08:24 <SumitNaiksatam> #endmeeting