18:02:30 <tbachman> #startmeeting gbp_status_arch 18:02:30 <odl_meetbot> Meeting started Fri Feb 27 18:02:30 2015 UTC. The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html. 18:02:30 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:30 <odl_meetbot> The meeting name has been set to 'gbp_status_arch' 18:02:46 <tbachman> #chair alagalah 18:02:46 <odl_meetbot> Current chairs: alagalah tbachman 18:02:59 <alagalah> #topic Agenda 18:03:03 <alagalah> #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:STATUS#Team_Meeting 18:03:11 <alagalah> #topic Code Merges 18:03:23 <tbachman> #link https://meetings.opendaylight.org/opendaylight-group-policy/2015/gbp_status_arch/opendaylight-group-policy-gbp_status_arch.2015-02-20-18.00.html Minutes from last week’s meeting 18:04:01 <tbachman> alagalah: we should cover action items from last week 18:04:12 <tbachman> I had two 18:04:16 <alagalah> tbachman: good call 18:04:20 <alagalah> Can you put them in 18:05:02 <tbachman> #action tbachman to follow up with mickey_spiegel re: this email: https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000886.html 18:06:08 <alagalah> #info tbachman followed up on how to track other projects bugs that affect us. Feedback was: create a 'megabug' that we link the external bugs to the 'megabug' and get notifications that way 18:08:05 <tbachman> #action tbachman to file metabug for the Lithium release to track bugs outside of the groupbasedpolicy project (e.g. openflowplugin, controller), and link bugs to this metabug 18:09:27 <tbachman> #info Daniel Konig-Schieber says that deny-all and allow-specific might be too-light a definition for multiple renders — wonders if we can define a set for renderers to support 18:09:42 <tbachman> #info edwarnicke says that in yang, the enum types is not extensible 18:09:54 <tbachman> #info edwarnicke says you can achieve the same effect using identities 18:10:19 <tbachman> #info edwarnicke says the overlay project uses this for tunnel types 18:10:54 <tbachman> #action alagalah to look into replacing enums in GBP modesl with identities 18:11:22 <tbachman> #info edwarnicke says it also brings in augmentations for the tunnel type 18:12:36 <tbachman> #info alagalah says when we get into event and exception management/reporting, this allows renderers to specify whatever they want 18:14:05 <tbachman> #info alagalah says he can see a middle-ground case where the model can supports a lot of different classifier types, etc. but have an agreement on a base set of types to start with in the model 18:14:30 <tbachman> #info mickey_spiegel says when we modify the model, the question is whether there are common ones and renderer-specific ones 18:15:18 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000830.html email from Daniel on subject-feature-definitions 18:15:37 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000886.html email from mickey_spiegel on the same topic 18:15:43 <tbachman> #action alagalah to follow up on this 18:16:20 <tbachman> #info Sanjay says that we haven’t had a model discussion in the meeting, and wanted to bring up some of the topics — priority, etc. Should we have a discussion and whether or not they will be added to the model now 18:16:34 <tbachman> #info alagalah says we will try to fit it at the end of today 18:16:49 <tbachman> #info alagalah says if not in today’s meeting then next week’s meeting 18:17:49 <tbachman> #topic Code merges 18:19:09 <abhijitkumbhare> #info Good job tbachman & edwarnicke :) 18:22:16 <tbachman> abhijitkumbhare: thx ;) 18:22:30 <tbachman> #topic Trello 18:23:00 <tbachman> #info alagalah is working on setting up a lab environment that’s externally accessible 18:23:48 <tbachman> #info The environment would have VMs that would be set up to run the POC, so that people in the community can test things like neutron integration and SFC integration 18:23:58 <tbachman> #link https://trello.com/b/yc0xHFlv/opendaylight-groupbasedpolicy-lithium Trello board link 18:24:21 <tbachman> #info port range was completed this weekend 18:24:50 <tbachman> #info alagalah is going to document the inter-EPG policy on the wiki before moving to done 18:25:55 <tbachman> #info martin_sunal is workin gon the Neutron API mapping — provided a patch that’s WIP 18:26:41 <tbachman> #link https://git.opendaylight.org/gerrit/#/c/15621 Gerrit that provides the neutron to GBP mapping 18:26:45 <tbachman> s3wong: ^^^ :) 18:27:00 <s3wong> tbachman: hello 18:27:10 <s3wong> sorry, out of the desk for a while 18:27:15 <tbachman> #action alagalah to provide weekly updates on the neutron to GBP mapping 18:27:20 <tbachman> s3wong: no worries ;) 18:27:29 <tbachman> s3wong: you may be interested in that gerrit above 18:27:47 <s3wong> tbachman: OK, I will put myself as a reviewer 18:27:48 <tbachman> #info alagalah says we have about 95% unit test coverage on GBP inheritance 18:27:51 <tbachman> s3wong: thx! 18:28:46 <tbachman> #link https://wiki.opendaylight.org/view/Group_Policy:Architecture/Policy_Model#Inheritance Link that describe how inheritance is supposed to work in GBP — what needs to be tested functionally 18:29:36 <tbachman> #info alagalah has linked the common tenant and inheritance tasks on the trello board, as implementing the common tenant may be achievable using inheritance 18:31:01 <tbachman> #info alagalah says to meet the needs of security groups, it was simpler to allow EPs to join multiple EPGs, rather than leverage conditions 18:31:11 <tbachman> #info alagalah tried out conditions and multi-EPGs 18:31:32 <tbachman> #info alagalah says after testing both, multi-EPG seems to be the right path 18:31:58 <tbachman> #info alagalah says conditions can do things that muilti-EPG can’t, so both have their use cases 18:33:33 <tbachman> #info mickey_spiegel says if you allow multiple EPGs per endpoint, you can have conflicts — has that been addressed 18:34:35 <tbachman> #info alagalah says his initial thoughts are based on the fact that one of the reasons at including multi-EPG is to meet a requirement for neutron security groups 18:35:04 <s3wong> tbachman, alagalah: is multi-EPGs for EP need for SG because a Neutron port can be associated with multiple SGs? 18:35:18 <tbachman> edwarnicke: ^^^^ 18:35:38 <edwarnicke> s3wong: Among other things, yes 18:35:47 <edwarnicke> s3wong: It turns out to be mega handy in many dimensions 18:35:53 <tbachman> #info alagalah says one of the ideas is looking at things at the same level as the classifier, at the same level you can do an OR, since you won’t have a conflict 18:36:42 <tbachman> #info mickey_spiegel says this is probably a longer discussion; openstack got away with it b/c it’s only allow 18:36:53 <tbachman> #info mickey_spiegel says with more actions, it becomes more complicated 18:40:26 <tbachman> #info alagalah says he’d like to see us get to the point where we do more than just “give me a chain by name” — like provide the list of things desired 18:40:33 <tbachman> #undo 18:40:33 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1a9db50> 18:40:44 <tbachman> #info alagalah says he’d like to see us get to the point where we do more than just “give me a chain by name” — like provide the list of services desired 18:41:08 <tbachman> #info alagalah says some of this might be part of a post-Lithium discussion 18:42:06 <tbachman> #info Daniel asks if he should provide the precedence on the classifiers 18:42:29 <s3wong> yapeng: I got error when I tried to look at your gerrit (15814)? 18:43:39 <tbachman> s3wong: ah — it’s a draft 18:43:41 <tbachman> he has to add you 18:43:45 <tbachman> he’s going to push it to master 18:43:46 <yapeng> i made mistake when submit patch, i submit to HEAD/draft/master. Should be "HEAD:refs/for/master" 18:44:02 <yapeng> i will fix this problem today. 18:44:08 <s3wong> yapeng: thanks 18:44:27 <yapeng> s3wong, do you know could i change this when i push updated patch? 18:44:38 <tbachman> #info alagalah says for SFC, we can use whatever encap we want, but when it reaches the tunnel, it does the NSH encap 18:45:37 <s3wong> yapeng: not sure --- you meant the branch, right? 18:45:50 <s3wong> yapeng: if so, you should be able to update that field 18:46:55 <tbachman> #info yapeng has a draft that he’s pushed on the simultaneous renderer support 18:51:12 <tbachman> #action start a design doc for supporting simultaneous renderers, link to trello card, and contact all parties invovled 18:53:09 <yapeng> s3wong, thanks i will take a look 18:53:24 <tbachman> #info alagalah sasys the card “Move FD/BD/Subnet selection to EP” has to do with supporting the data plane using the constructs in the EP 18:55:52 <tbachman> #info yapeng has tested the URI change in openstack to use the new URI — it works. He just needs the final name to be used (tbd) 18:59:19 <tbachman> #info alagalah is looking at revamping the wiki to make it more consumable 19:07:23 <tbachman> #action tbachman to retest performance and reach out to jmedved and moizer on the results 19:07:26 <tbachman> #topic Documentation 19:07:37 <tbachman> #info alagalah to be the guineau pig for documentation project 19:07:43 <tbachman> #topic Endpoint Model discussion 19:08:25 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000953.html email from alagalah on the port name parameter when registering Endpoints 19:10:33 <tbachman> #info alagalah says that for the openstack use case, neutron knows the tap port name at the time of port registration 19:11:05 <tbachman> #link https://docs.google.com/a/noironetworks.com/document/d/1VGvRZxLaKqt_bqjriRlIjLDjXJPBFvZ5_9puNUj3I94/edit Google doc showing the existing ML2 mechanism driver sequence diagram and sequence diagram for OpenStack GBP/ODL GBP integration 19:12:38 <tbachman> #info alagalah is proposing moving the port-name construct to an augmentation, and adding the node and the bridge to that augmentation 19:13:23 <tbachman> #info Sanjay says there’s an implementation for a different vSwitch, which is slightly different 19:14:11 <tbachman> #info Sanjay says instead of using a nova agent to create and attach a virtual port to the bridge, and then notify neutron, they are having nova create the port on the VM and then have neutron notify ODL from the neutron interface 19:14:35 <tbachman> #info Sanjay says you can specify the host ID in the create/update port command 19:15:18 <tbachman> #info alagalah points out that we don’t have a neutron integration yet 19:15:59 <tbachman> #info Sanjay says that OVS is a special implementation where nova attaches the host port 19:16:26 <tbachman> #link http://developer.openstack.org/api-ref-networking-v2.html Link that Sanjay is using to show the neutron API 19:16:58 <tbachman> #info Sanjay says the only entity that knows where the VM was created is nova 19:18:06 <tbachman> #info Sanjay says there’s no way to tell where the port is created among all the hypervisors, but they discovered the ability to get the host ID 19:18:44 <tbachman> #info Sanjay says that allows them to take the port name and attach it to their virtual switch 19:19:32 <tbachman> #info alagalah asks how moving a field from the general endpoint to an augmentation in the renderer affects this 19:20:46 <tbachman> #info Sanjay says the property of which renderer is using information that’s relevant to the NB application 19:37:46 <tbachman> #info alagalah agrees with Sanjay that we need a separation of concerns between northbound semantics and southbound semantics 19:38:32 <tbachman> #info alagalah asks if Sanjay is okay with the existing proposal, with the caveat that the northbound/southbound semantics need to be addressed 19:38:46 <tbachman> #info Sanjay feels that location should be in the base endpoint model 19:39:15 <tbachman> #info edwarnicke disagrees somewhat. He says that VMs are only one piece of this picture 19:39:43 <tbachman> #info edwarnicke says he suggests having a common location augmentation that could be used by multiple northbound applications 19:39:55 * tbachman wonders if we’re going back to inventory discussions :O 19:40:23 <tbachman> #info Sanjay says that the string may be different, but there has to be a location 19:41:17 <tbachman> #info edwarnicke says there are cases where there isn’t location information but we want to control the EP 19:43:45 <tbachman> #info Sanjay asks the case where you have two renderers, how do you augment the endpoint registry model in a coordinated way 19:44:17 <tbachman> #info alagalah says that’s the simultaneous renderer problem, which is being addressed 19:48:50 <tbachman> #info Daniel asks how you can apply a policy to something that has only a location 19:49:02 <tbachman> #info alagalah isn’t sure how that will work when there’s no L2/L3 keys 19:49:36 <tbachman> #info Daniel says that if we have another index that covers location, that might help 19:49:43 <tbachman> #endmeeting