18:00:03 <tbachman> #startmeeting gbp_status_arch 18:00:03 <odl_meetbot> Meeting started Fri Jan 23 18:00:03 2015 UTC. The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html. 18:00:03 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:03 <odl_meetbot> The meeting name has been set to 'gbp_status_arch' 18:00:06 <tbachman> #chair alagalah_ 18:00:06 <odl_meetbot> Current chairs: alagalah_ tbachman 18:00:11 <tbachman> #topic agenda 18:00:17 <tbachman> #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:STATUS#Team_Meeting Agend for today’s meeting 18:00:24 <alagalah_> tbachman: Thanks mate 18:00:27 <tbachman> alagalah_: np! 18:00:42 <tbachman> #link https://meetings.opendaylight.org/opendaylight-group-policy/2015/gbp_status_arch/opendaylight-group-policy-gbp_status_arch.2015-01-02-18.00.html The last meeting minutes that we have 18:01:03 <tbachman> #topic GBP as Neutron Provider 18:04:03 <tbachman> 2 more mins folks :) 18:05:06 <tbachman> #info GBP can bring benefits to NFV, but to do that, we need to implement a provider to the neutron API 18:05:59 <tbachman> #info There are some model enhancements made in order to support this 18:06:14 <tbachman> #info the ODL neutron service will be re-used, and will interface to a neutron-to-GBP translator 18:06:29 <tbachman> #link https://docs.google.com/presentation/d/1AO47EYrDMuTAypcpYbL3XOKFggZXu9x00XpGVwJLr9o/edit#slide=id.p presentation that alagalah_ is doing 18:06:42 <tbachman> #info Endpoints belong to groups, and the groups interact diretionally using contracts 18:07:33 <tbachman> #endpoints live in a network context, which can be an L2-Bridge Domain, L3 domain (like a VRF) 18:07:45 <yapeng_> tbachman: the slide deck need permission to read. 18:07:49 <tbachman> #info Endpoint Groups can specify a default netowkr context for members 18:07:51 <tbachman> yapeng_: ah 18:08:03 <tbachman> I’ll have to wait for alagalah_ — I think he owns it 18:08:07 <tbachman> let him run the preso 18:08:11 <tbachman> then he’ll change the permissions 18:08:20 <tbachman> yapeng_: thx for letting us know! 18:08:22 <yapeng_> sure. thanks 18:09:02 <tbachman> #info Neutron maps well into GBP — network is a bridge domain, port is an Endpoint, Subnet is a subnet, Security group is an Endpoint Group, and Routers are an L3 context 18:10:11 <tbachman> #info alagalah_ says that policy dictates what traffic can pass; with security groups in neutron, a new EPG is created to map to the neutron security group 18:10:53 <tbachman> #info an endpoint (port) can then participate in the security group EPG and it’s other EPG 18:11:06 <tbachman> #info dbainbri asks if there’s any conflicts when an EP belongs to more than one security group 18:11:55 <tbachman> #info alagalah_ says he hasn’t seen anything concrete in terms of conflicts; because it’s a white list model, there’s no ordering, but if there’s ordering needed as a use case, it wouldn’t be hard to add it to the model 18:12:13 <tbachman> #info mickey_spiegel says that you don’t have conflicts is b/c it’s all allow rules 18:12:31 <tbachman> #info Prem asks if there will be an hierarchical ordering with security groups 18:12:43 <tbachman> #info alagalah_ says that the existing model supports inheritance, so it could support that 18:13:24 <tbachman> #info A NAT Endpoing Group can be created and join that group in order to implement NAT 18:13:31 <tbachman> #undo 18:13:31 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x19427d0> 18:13:41 <tbachman> : #info A NAT Endpoing Group can be created and an Endpoint can join that group in order to implement NAT 18:13:44 <tbachman> dang 18:13:57 <tbachman> #info A NAT Endpoing Group can be created and an Endpoint can join that group in order to implement NAT 18:14:00 <tbachman> there we go :) 18:14:18 <tbachman> #info A similar concept can be used with LBaaS 18:14:52 <tbachman> #info for SFC, it’s a bit different, where the service chain is defined by the contract; the EPGs define the relationship to select the contract that implements the chain 18:15:15 <tbachman> #info alagalah_ shows that OpenStack passes calls to the ODL Neutron service (via ODL pass-thru neutron Plugin) 18:15:30 <tbachman> #info There will be a neutron to GBP translation layer, which then passes things on to GBP 18:16:00 <tbachman> #info The neutron to GBP translator doesn’t exist today; we need some changes to the model (EP in multiple EPGs) 18:16:10 <tbachman> #info There are also some changes to help some forwarding model constructs 18:16:47 <tbachman> #info abhijitkumbhare asks where the GBP openstack fits in this model 18:16:56 <tbachman> #info alagalah_ says this is just passing straight neutron to ODL 18:17:06 <tbachman> #info abhijitkumbhare asks if we’re using GBP in openstack 18:17:32 <tbachman> #info alagalah_ says we’ve already done that integration, but we want to implement a neutron interface in order to support NFV use cases 18:18:05 <tbachman> #info alagalah_ says that automated testing setup is needed — not just for this, but for all of ODL — in order to run tempest testing against any neutron provider 18:18:35 <tbachman> #info daniel asks if the actions like LBaaS and others are defined, or are these defined by what the renderer supports 18:18:41 <tbachman> #info alagalah_ says this is more in the renderer 18:18:56 <tbachman> #info daniel says he thinks it would be worthwhile to have a minimal set of action enums defined 18:19:16 <tbachman> #info alagalah_ says there’s an enumerated type in the yang model, which currently is only allow 18:19:43 <tbachman> #info daniel says there are at least 4 different kinds of actions that they have use cases for 18:20:18 <tbachman> #info Louis asks if the redirect to a service chain has been covered 18:20:30 <tbachman> #info alagalah_ says that’s what the project is looking at 18:20:51 <tbachman> #info cdub asks how you map the VIF UUID to the policy group (did I get that right?) 18:21:41 <tbachman> #info cdub asks if the ODL constructs are part of a CRUD call, or are they policies 18:21:51 <tbachman> #info cdub says there is no service chain APIs in neutron 18:22:08 <tbachman> #info This means openstack would have to inform ODL with the unique policy ID 18:23:15 <tbachman> #info Rajeev asks how things are passed from neutron — e.g. policies specific to SFC 18:23:31 <tbachman> #info edwarnicke says that neutron constructs must be self contained and are passed thru 18:23:46 <tbachman> #info edwarnicke says that constructs that aren’t in neutron have to be piggy-backed 18:24:37 <tbachman> #info Rajeev asks if an opaque container could be passed through neutron and given to ODL’s SFC 18:24:42 <tbachman> #info edwarnicke says that’s certainly possible 18:25:35 <tbachman> #info Rajeev says that this was brought up at the OpenStack design summit and said that we needed to look at the use cases; we may have a use case now 18:25:55 <tbachman> #info alagalah_ will update the release plan and trello board with these tasks 18:26:09 <tbachman> #topic Project status update 18:26:37 <tbachman> #info alagalah_ says that openstack GBP integration is complete 18:28:13 <tbachman> #info tbachman has been working on the opflex renderer — patch is outstanding 18:28:23 <tbachman> #endmeeting