17:04:34 #startmeeting model 17:04:34 Meeting started Fri May 9 17:04:34 2014 UTC. The chair is regXboi. Information about MeetBot at http://ci.openstack.org/meetbot.html. 17:04:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:04:34 The meeting name has been set to 'model' 17:04:39 #chair alagalah 17:04:39 Current chairs: alagalah regXboi 17:04:39 #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:MODEL#Information_From_Past_Meetings 17:04:44 #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:MODEL#Information_From_Past_Meetings 17:06:55 #info dvorkinista s3wong dconde will be at OpenStack summit next week. Meetings will proceed as normal and if we don't have critical mass will keep them short. 17:07:05 #topci 17:07:18 #topic action item alagalah: Review of JSON derived from Wed May7 whiteboard session (pic to come) 17:07:33 #info alagalah has not had time, will address over the weekend 17:07:56 #action alagalah to take whiteboard diagram of 3tier app with UML representations (pic to come) and turn into JSON over the weekend 17:08:19 #topic Action items from last week 17:08:53 #info these action items are too hard to decipher: ignoring: Review of JSON derived from Wed May7 whiteboard session (pic to come) 17:09:05 we need to handoff to DATASTORE subgroup to have more detailed requirements. jmedved 17:09:05 to modeling group to deal with directionality. 17:09:05 is for readams and dvorkinista 17:09:07 #info these action items are too hard to decipher: ignoring: 17:09:10 we need to handoff to DATASTORE subgroup to have more detailed requirements. jmedved 17:09:11 to modeling group to deal with directionality. 17:09:13 is for readams and dvorkinista 17:09:31 #info Action item: dvorkinista (Mike D) to modify Matcher logic to be either ANDs, ORs, with Label EXCLUDE for negation. This will be a single level ie (A AND B AND C), (A OR B OR C), EXCLUDE (A AND B) 17:10:38 #info this action item has been resolved, matcher logic has been updated and is represented in the Yang model and is up on the repo (pull at will). List of labels and can say ALL, NONE, or ANY and on labels have INCLUDE/EXCLUDE 17:10:53 #info alagalah will write a whitepaper that describes the UML model. 17:11:20 #link https://meetings.opendaylight.org/opendaylight-group-policy/2014/model/opendaylight-group-policy-model.2014-05-02-17.05.html minutes from previous meeting 17:11:52 #info Mickey just came in 17:12:22 #action alagalah to instead of writing whitepaper or annotating the UML to write a PPT with animations that describes the UML model with annotations. 17:12:42 #info It should be noted that Rob's YANG model will be the "single source of truth" moving forward. 17:12:55 truth, justice and american way 17:12:56 What is webex please? 17:13:03 no webex - google hangout 17:13:03 No webex 17:13:08 hold 1 for link 17:13:14 https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.6msm68t31c5fdn152g721o09ks?authuser=1 17:13:19 #link https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.6msm68t31c5fdn152g721o09ks?authuser=1 17:13:26 #info above is google hangout 17:13:47 #info welcome dave 17:14:23 #info dvorkinista to restruct model in structure, definition use. 17:14:33 #action dvorkinista to restruct model in structure, definition use - has not had time. 17:14:49 alagalah will talk w/ ed warnicke regarding service chaining. 17:14:57 we are using hangout 17:15:06 #info from last week: alagalah will talk w/ ed warnicke regarding service chaining... this didn't happen 17:15:56 #action alagalah regXboi edwarnicke to discuss service chaining, specifically their datastore/subscription requirements and how they are planning on addressing this with MD-SAL etc 17:17:27 #info Whiteboard use cases from DATASTORE team meeting (will link minutes from that meeting). 17:18:13 #action alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May5 17:18:17 #action alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May9 17:21:36 #topic Review of YANG model committed to the repo for EPR/PR 17:22:39 coke zero: +1 17:23:03 #info uchau proposes going over documentation generated from YANG to JSON, readams suggests it would be more useful to go over the YANG model as there are still outstanding issues being worked through with the MD-SAL folks. 17:23:06 readams: +1 to coke zero 17:23:16 regXboi: He has an IV drop of the stuff 17:23:20 *drip 17:23:30 alagalah: watch the video from me 17:25:21 #info readams points out that there are mandatory elements of the model, which will throw an error if not present, but for things like lists we can modify. 17:26:10 I dropped out if someone wants to join 17:27:13 #link Repo: git clone https://git.opendaylight.org/gerrit/p/groupbasedpolicy.git 17:28:55 #info readams sharing updated YANG model in hangout. This will be pushed when ready, no ETA but existing repo is a "good start" 17:31:03 #topic Review of policy.yang by readams 17:31:34 #info readams speaking: The model has important stuff in it and a lot of random cruft in there to make object hierarchy et al reasonable 17:31:52 #info Best place to start is tenants container. Tenant has UUID, name, description user can fill in. 17:32:14 #info Below this are EPGs, contracts, and contract-references for cross-tenant contracts 17:33:25 #info Underneath EPG, have a UUID, list of selectors (provider-name|provider-target|consumer-named|consumer-target) 17:33:48 #info definition of these is relatively simple, and various combinations from either side of consumer/provider 17:34:30 #info consumer-selection-relator has has-requirements and provider-selector-relator has has-capabilities 17:34:55 #info dvorkinista asks how we avoid loops, readams says we can't in YANG will require code to check. 17:35:09 #info dvorkinista asks about multiple inheritance... didn't get answer 17:35:53 #info dvorkinista points out that now we have chaining (due to lack of recursive inheritance) things may get messy ... not inheritance anymore in the tree, its more association via linked-list 17:36:35 #info readams says we have the possibility to go from a tree to a DAG, which may not be bad (DAG = Directed Acyclical Graph... google it, its cool) 17:37:37 #info quality-matcher has matchers (ie a matched type) ... note qualities can be thought of as a "label" but we chose not to say "label" as the term gets overloaded 17:38:21 #info matcher-selector has matcher-quality ... in that its like a normal quality (ie label) but it has a name-space associated with it, so you can specificy a name rather than just labels and possibly getting overlap 17:39:04 #info Could potentially rename name-space to "name" as its directed to a specific entity rather than a quality (ie label ) search for match 17:39:43 #info dvorkinista says we have a semantic issue. If we look at the target, i can either specify the name(-space), inherit it, or put "any" 17:40:08 #info dvorkinista Says we could also use the name of the selector as the name(-space) .. .by renaming the selector the same as the target. 17:40:40 #info dvorkinista says this can be useful, so if I have a selector looking for "foo" I can get all the contracts with "foo" 17:42:10 #info mickey asks about target selectors etc and inheritance... dvorkin says we can just use labels (qualities) and can't have expressions on target name, but can have expressions on qualities 17:42:48 #info readams says its difficult to represent all this, espec. with "*" not supported for name, can do Unions but the java is generated is problematic. 17:43:04 #info dvorkin asks if YANG can set a default value on strings, such as "*" 17:43:26 #info alagalah is wondering that we treat "*" the string and match on that and treat as wildcard 17:44:48 #info Default behaviour of selector is if there are specific semantics in that object in the tree, we use that, else we goto parent and inherit etc 17:45:20 #info name selector or target selector usses names or qualities to find list of contracts in scope. 17:45:25 #info then their job is finished 17:45:44 #info next stage is identifying which subjects apply within the contract between EP(con) and EP(prov) 17:46:24 #info Take clauses, which look at req/cap * conditions, and once this is resolved (ie an "accord") this results which subjects are in scope 17:46:46 #info subjects are applied to traffic, within subjects we have rules that match again classifiers on traffic and actions that act on that traffic 17:47:06 #info Getting from registration to traffic flow instantiation is a multi-layer process that occurs in phases 17:48:01 #info mickey asks about where req/cap/cond reside (EP or EPG) dvorkin says conditions can apply to EPG but readams points out that the current YANG implementation doesn't support that today (our implementation, not a YANG limitation) 17:48:37 #info readams have to resolve EP conditions AND EPG conditions ... 17:49:17 #info readams brings up proactive can be a nightmare, alagalah asks that we move this to ARCH, dvorkin points out that this should be a RE 17:49:25 #info RENDERER decision 17:51:03 #info Discussion about conditions and their implementation where we don't modulate configuration. 17:52:00 #info readams made the philosophical comment that a dynamic state variable (conditions) should not be in the EPG configuration, but be in the EPR 17:52:02 #info readams made claim that adding conditions to EPG is a bad idea. Conditions are dynamic, shouldn't be in EPG state. So rather than putting it in EPG, put it in EPR and allow the condition to apply to multiple EPs or EPG in EPR 17:52:30 #info Condition is a modulator, ie it augments the req/cap matching case to define what subjects are in scope 17:53:41 #action alagalah/readams to record a YouTube video going through the YANG model sometime before May16 (next Fri MODEL meeting) 17:55:25 #action readams to start working on ARCHITECTURE documentation / Functional Spec starting next week. We will do the YouTube video post that 17:57:15 #info consumer-matchers has requirements matchers and consumers conditions matchers and provider matchers is the mirror (caps * cond) 17:58:12 #info Clause then references a particular subject in the YANG but in the UML it references multiple subjects 17:58:55 #action readams to investigate if the YANG model can be changed to support a clause referencing multiple subjects ( #info Clause then references a particular subject in the YANG but in the UML it references multiple subjects) 18:00:12 #info classifier-refs ref classifier-instances which are defined in a tenant (defined globally), and is a parameterized thing like match TCP port. 18:00:32 #info classifier instance of "HTTP" so TCP ports classifier with a parameter of 80 18:01:33 #action alagalah to have a stab at seeing if there is a graphical way of representing policy.yang (ie tree of this yang) 18:04:05 #info alagalah stepped away to get phone as expecting call for ARCH meeting (MODEL meeting has officially run over) 18:05:55 #info more discussion of the tenant model 18:06:37 #endmeeting