#opendaylight-group-policy: model

Meeting started by regXboi at 17:04:34 UTC (full logs).

Meeting summary

    1. https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:MODEL#Information_From_Past_Meetings (alagalah, 17:04:39)
    2. https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:MODEL#Information_From_Past_Meetings (alagalah, 17:04:44)
    3. 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. (alagalah, 17:06:55)

  2. action item alagalah: Review of JSON derived from Wed May7 whiteboard session (pic to come) (alagalah, 17:07:18)
    1. alagalah has not had time, will address over the weekend (alagalah, 17:07:33)
    2. ACTION: alagalah to take whiteboard diagram of 3tier app with UML representations (pic to come) and turn into JSON over the weekend (alagalah, 17:07:56)

  3. Action items from last week (alagalah, 17:08:19)
    1. these action items are too hard to decipher: ignoring: Review of JSON derived from Wed May7 whiteboard session (pic to come) (alagalah, 17:08:53)
    2. these action items are too hard to decipher: ignoring: (alagalah, 17:09:07)
    3. 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) (alagalah, 17:09:31)
    4. 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 (alagalah, 17:10:38)
    5. alagalah will write a whitepaper that describes the UML model. (alagalah, 17:10:53)
    6. https://meetings.opendaylight.org/opendaylight-group-policy/2014/model/opendaylight-group-policy-model.2014-05-02-17.05.html minutes from previous meeting (regXboi, 17:11:20)
    7. Mickey just came in (dconde, 17:11:52)
    8. ACTION: alagalah to instead of writing whitepaper or annotating the UML to write a PPT with animations that describes the UML model with annotations. (alagalah, 17:12:22)
    9. It should be noted that Rob's YANG model will be the "single source of truth" moving forward. (alagalah, 17:12:42)
    10. https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.6msm68t31c5fdn152g721o09ks?authuser=1 (alagalah, 17:13:14)
    11. https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.6msm68t31c5fdn152g721o09ks?authuser=1 (regXboi, 17:13:19)
    12. above is google hangout (regXboi, 17:13:26)
    13. welcome dave (regXboi, 17:13:47)
    14. dvorkinista to restruct model in structure, definition use. (alagalah, 17:14:23)
    15. ACTION: dvorkinista to restruct model in structure, definition use - has not had time. (alagalah, 17:14:33)
    16. from last week: alagalah will talk w/ ed warnicke regarding service chaining... this didn't happen (alagalah, 17:15:06)
    17. 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 (alagalah, 17:15:56)
    18. Whiteboard use cases from DATASTORE team meeting (will link minutes from that meeting). (alagalah, 17:17:27)
    19. ACTION: alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May5 (alagalah, 17:18:13)
    20. ACTION: alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May9 (alagalah, 17:18:17)

  4. Review of YANG model committed to the repo for EPR/PR (alagalah, 17:21:36)
    1. 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. (alagalah, 17:23:03)
    2. 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. (alagalah, 17:25:21)
    3. Repo: git clone https://git.opendaylight.org/gerrit/p/groupbasedpolicy.git (alagalah, 17:27:13)
    4. readams sharing updated YANG model in hangout. This will be pushed when ready, no ETA but existing repo is a "good start" (alagalah, 17:28:55)

  5. Review of policy.yang by readams (alagalah, 17:31:03)
    1. readams speaking: The model has important stuff in it and a lot of random cruft in there to make object hierarchy et al reasonable (alagalah, 17:31:34)
    2. Best place to start is tenants container. Tenant has UUID, name, description user can fill in. (alagalah, 17:31:52)
    3. Below this are EPGs, contracts, and contract-references for cross-tenant contracts (alagalah, 17:32:14)
    4. Underneath EPG, have a UUID, list of selectors (provider-name|provider-target|consumer-named|consumer-target) (alagalah, 17:33:25)
    5. definition of these is relatively simple, and various combinations from either side of consumer/provider (alagalah, 17:33:48)
    6. consumer-selection-relator has has-requirements and provider-selector-relator has has-capabilities (alagalah, 17:34:30)
    7. dvorkinista asks how we avoid loops, readams says we can't in YANG will require code to check. (alagalah, 17:34:55)
    8. dvorkinista asks about multiple inheritance... didn't get answer (alagalah, 17:35:09)
    9. 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 (alagalah, 17:35:53)
    10. 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) (alagalah, 17:36:35)
    11. 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 (alagalah, 17:37:37)
    12. 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 (alagalah, 17:38:21)
    13. Could potentially rename name-space to "name" as its directed to a specific entity rather than a quality (ie label ) search for match (alagalah, 17:39:04)
    14. 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" (alagalah, 17:39:43)
    15. dvorkinista Says we could also use the name of the selector as the name(-space) .. .by renaming the selector the same as the target. (alagalah, 17:40:08)
    16. dvorkinista says this can be useful, so if I have a selector looking for "foo" I can get all the contracts with "foo" (alagalah, 17:40:40)
    17. 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 (alagalah, 17:42:10)
    18. readams says its difficult to represent all this, espec. with "*" not supported for name, can do Unions but the java is generated is problematic. (alagalah, 17:42:48)
    19. dvorkin asks if YANG can set a default value on strings, such as "*" (alagalah, 17:43:04)
    20. alagalah is wondering that we treat "*" the string and match on that and treat as wildcard (alagalah, 17:43:26)
    21. 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 (alagalah, 17:44:48)
    22. name selector or target selector usses names or qualities to find list of contracts in scope. (alagalah, 17:45:20)
    23. then their job is finished (alagalah, 17:45:25)
    24. next stage is identifying which subjects apply within the contract between EP(con) and EP(prov) (alagalah, 17:45:44)
    25. Take clauses, which look at req/cap * conditions, and once this is resolved (ie an "accord") this results which subjects are in scope (alagalah, 17:46:24)
    26. subjects are applied to traffic, within subjects we have rules that match again classifiers on traffic and actions that act on that traffic (alagalah, 17:46:46)
    27. Getting from registration to traffic flow instantiation is a multi-layer process that occurs in phases (alagalah, 17:47:06)
    28. 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) (alagalah, 17:48:01)
    29. readams have to resolve EP conditions AND EPG conditions ... (alagalah, 17:48:37)
    30. 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 (alagalah, 17:49:17)
    31. RENDERER decision (alagalah, 17:49:25)
    32. Discussion about conditions and their implementation where we don't modulate configuration. (alagalah, 17:51:03)
    33. readams made the philosophical comment that a dynamic state variable (conditions) should not be in the EPG configuration, but be in the EPR (regXboi, 17:52:00)
    34. 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 (alagalah, 17:52:02)
    35. Condition is a modulator, ie it augments the req/cap matching case to define what subjects are in scope (alagalah, 17:52:30)
    36. ACTION: alagalah/readams to record a YouTube video going through the YANG model sometime before May16 (next Fri MODEL meeting) (alagalah, 17:53:41)
    37. ACTION: readams to start working on ARCHITECTURE documentation / Functional Spec starting next week. We will do the YouTube video post that (alagalah, 17:55:25)
    38. consumer-matchers has requirements matchers and consumers conditions matchers and provider matchers is the mirror (caps * cond) (alagalah, 17:57:15)
    39. Clause then references a particular subject in the YANG but in the UML it references multiple subjects (alagalah, 17:58:12)
    40. 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) (alagalah, 17:58:55)
    41. classifier-refs ref classifier-instances which are defined in a tenant (defined globally), and is a parameterized thing like match TCP port. (alagalah, 18:00:12)
    42. classifier instance of "HTTP" so TCP ports classifier with a parameter of 80 (alagalah, 18:00:32)
    43. ACTION: alagalah to have a stab at seeing if there is a graphical way of representing policy.yang (ie tree of this yang) (alagalah, 18:01:33)
    44. alagalah stepped away to get phone as expecting call for ARCH meeting (MODEL meeting has officially run over) (alagalah, 18:04:05)
    45. more discussion of the tenant model (regXboi, 18:05:55)


Meeting ended at 18:06:37 UTC (full logs).

Action items

  1. alagalah to take whiteboard diagram of 3tier app with UML representations (pic to come) and turn into JSON over the weekend
  2. alagalah to instead of writing whitepaper or annotating the UML to write a PPT with animations that describes the UML model with annotations.
  3. dvorkinista to restruct model in structure, definition use - has not had time.
  4. alagalah regXboi edwarnicke to discuss service chaining, specifically their datastore/subscription requirements and how they are planning on addressing this with MD-SAL etc
  5. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May5
  6. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May9
  7. alagalah/readams to record a YouTube video going through the YANG model sometime before May16 (next Fri MODEL meeting)
  8. readams to start working on ARCHITECTURE documentation / Functional Spec starting next week. We will do the YouTube video post that
  9. 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)
  10. alagalah to have a stab at seeing if there is a graphical way of representing policy.yang (ie tree of this yang)


Action items, by person

  1. alagalah
    1. alagalah to take whiteboard diagram of 3tier app with UML representations (pic to come) and turn into JSON over the weekend
    2. alagalah to instead of writing whitepaper or annotating the UML to write a PPT with animations that describes the UML model with annotations.
    3. alagalah regXboi edwarnicke to discuss service chaining, specifically their datastore/subscription requirements and how they are planning on addressing this with MD-SAL etc
    4. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May5
    5. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May9
    6. alagalah/readams to record a YouTube video going through the YANG model sometime before May16 (next Fri MODEL meeting)
    7. alagalah to have a stab at seeing if there is a graphical way of representing policy.yang (ie tree of this yang)
  2. lenrow
    1. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May5
    2. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May9
  3. regXboi
    1. alagalah regXboi edwarnicke to discuss service chaining, specifically their datastore/subscription requirements and how they are planning on addressing this with MD-SAL etc
    2. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May5
    3. alagalah meeting with Uyen, Rex, Dave Lenrow, regXboi to discuss Use-Case -> UML -> JSON "conversion" ... 14:30 Pac Fri May9
  4. UNASSIGNED
    1. dvorkinista to restruct model in structure, definition use - has not had time.
    2. readams to start working on ARCHITECTURE documentation / Functional Spec starting next week. We will do the YouTube video post that
    3. 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)


People present (lines said)

  1. alagalah (85)
  2. regXboi (13)
  3. odl_meetbot (4)
  4. dconde (2)
  5. lenrow (1)


Generated by MeetBot 0.1.4.