#opendaylight-group-policy: ARCH

Meeting started by dconde at 18:02:37 UTC (full logs).

Meeting summary

    1. https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.bps9id27mhd0pnqqljgjkckoqk?authuser=1 (raghu67, 18:07:39)
    2. on arch subgroup page, please expand box to see agenda stuff (dconde, 18:09:49)
    3. where is subscription? we need more aspects -- w.r.t. model (dconde, 18:10:06)
    4. impact of model on subscription and renderers (dconde, 18:10:19)

  2. agenda (dconde, 18:10:24)
    1. https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:ARCH (alagalah, 18:10:38)
    2. impact of model on subcr (dconde, 18:10:55)
    3. parent/child relationships is OK (dconde, 18:11:08)
    4. if we look at a contract, we get clauses, etc…. all in subtree (dconde, 18:11:22)
    5. in EPG, we get other stuff too. (dconde, 18:11:28)
    6. (that was Mickey) (alagalah, 18:11:35)
    7. we need to think about mult-tenancy, but let's ignore for now (dvorkinista) (dconde, 18:11:58)
    8. you get the groups, and then look at relators and know who you request information from. send a resolution request and get info back. "You==renderer-common" (dconde, 18:12:32)
    9. if I am a group and you are a contract, I should know where to go and where to request. Send a query to specify the selector. (dconde, 18:13:06)
    10. wokring on names is simple. labels are harder. (dconde, 18:13:32)
    11. dvorkinista qualities are used to resolve the contractts (dconde, 18:14:20)
    12. groups points to contracts. (dconde, 18:14:35)
    13. send it to the policy repo, it calculates what's in scope and send it back. (dconde, 18:14:48)
    14. who does that -- does MD-SAL? or something else. (dconde, 18:15:28)
    15. if not possible, then do at policy server or repository. (dconde, 18:15:46)
    16. what type of functionalty? we want to select contract based on its properties. like set of labels. (dconde, 18:16:13)
    17. mickey_spiegel asking who interprets the expression language. (dconde, 18:17:20)
    18. https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.bps9id27mhd0pnqqljgjkckoqk?authuser=1 (alagalah, 18:17:29)
    19. we need the notion of indexes defined on model attributes (raghu67, 18:17:37)
    20. we need an indexing mechanism by the qualities. (dconde, 18:17:57)
    21. is this an extension of YANG model? that is an option, says dvorkinista (dconde, 18:18:22)
    22. dvorkinista We want the model to be authoratative and a benefit is its self documenting, so ideally indexing should be part of the YANG model (alagalah, 18:19:41)
    23. this stuff needs to work really fast. (dconde, 18:20:04)
    24. readams says we can build it bespoke if needed. (dconde, 18:20:39)
    25. we may need to do datastore discussions. (dconde, 18:20:48)
    26. joking -- we don'to want to re-invent SQL! says readams. (dconde, 18:21:39)
    27. this is hard core work -- if we can impl slowly. once you add indices, query plans, it get to be harder to impl. (dconde, 18:22:13)
    28. ACTION: we need to handoff to DATASTORE subgroup to have more detailed requirements. jmedved (dconde, 18:23:55)
    29. who can define the queries that can be made? (dconde, 18:24:30)
    30. that is represented in the model, says readams. (dconde, 18:24:45)
    31. the selectors are representative of the queries (tbachman, 18:25:09)
    32. let's avoid this rathole (dconde, 18:26:20)

  3. subscriptions (dconde, 18:26:30)
    1. we subscribe to policies and resolve it the node that deals with it. continuously renders (dconde, 18:27:12)
    2. kinda like triggers in databases (dconde, 18:27:46)
    3. if you look at any system -- this is always useful -- (says dvorkinista) (dconde, 18:28:13)
    4. once you mutate you get notified. (dconde, 18:28:21)
    5. always push, not polling. (dconde, 18:28:35)
    6. this fits spirit of MD-SAL. (dconde, 18:29:01)
    7. we are data driven. says alagalah (dconde, 18:29:12)

  4. relationships (dconde, 18:29:45)
    1. mickey_spiegel lists some unidirectional vs. bidirectional. we need to agree on direction. (dconde, 18:30:15)
    2. picture shown on hangout? (dconde, 18:31:12)
    3. let mickey drive instead. (dconde, 18:31:18)
    4. not thought enough -- inheritance. (dconde, 18:31:41)

  5. inheritance (dconde, 18:31:47)
    1. impact on subscription. (dconde, 18:31:58)
    2. child refs parent (dconde, 18:33:21)
    3. policy resolution is leaves to parent nodel (dconde, 18:33:38)
    4. it's no longer CONTAINMENT -- it's chaining of child to parent. (dconde, 18:34:28)
    5. this is fundamental issue. (dconde, 18:34:36)
    6. the model is changing. (dconde, 18:37:50)
    7. we HAD containment. (dconde, 18:37:57)
    8. now, we have child with a sym link to parent. (dconde, 18:38:08)
    9. child specializes parent. (dconde, 18:38:29)
    10. contract with subjects are? (dconde, 18:38:49)
    11. we are talking about resolving policiy components. which is parent-child. (dconde, 18:39:28)

  6. renderers (dconde, 18:40:35)
    1. photo of whiteboard being email'ed (dconde, 18:43:27)
    2. going to -dev alias (dconde, 18:43:35)
    3. ACTION: to modeling group to deal with directionality. (dconde, 18:43:59)
    4. ACTION: is for readams and dvorkinista (dconde, 18:44:25)

  7. renderers (dconde, 18:44:51)
    1. first stmt. we don't want these extremes, but let's show them. 1) all state in universe and subscribe to all subtrees 2) other extreme is native renderer side. if stateless and relies on MD-SAL subscription, then we just transorm to whoever is below the renderer. The latter one is more interesting and better performing. (dconde, 18:45:50)
    2. the latter one needs to track which sub is for whom. (dconde, 18:46:08)
    3. we can add locational context to the EP Reg? (dconde, 18:46:43)
    4. dvorkonista says we may need a hint to map real object in renderer to EP reg (dconde, 18:47:06)
    5. readams if a renderer discovers dev on its own, how to add to the grp? (dconde, 18:48:03)
    6. it's the configuration of the renderer. this falls into operational aspect of renderer. but this is renderer specific. (dconde, 18:49:04)
    7. the time is getting near. (dconde, 18:49:23)
    8. this info is entered into renderer or into policy reposotiry. both are valid. we pick on, says dvorkinista. (dconde, 18:49:47)
    9. general constraints vs. impl specific. the latter can go into renderer. (dconde, 18:50:15)
    10. once in YANG model, readams may write a func spec of GBP. (dconde, 18:50:54)
    11. Is there going to be any operational state maintained by the renderers outside of MD-SAL Data store? (raghu67, 18:51:30)

  8. proactive vs reactive (dconde, 18:51:33)
    1. if ends points are coming and going, we need to be reactive to map to vswitch. (dconde, 18:52:16)
    2. getting anything off of EP cannot be done reactively (dconde, 18:54:08)
    3. do we need an arrow from eP to EPG? We can do a query instead. (dconde, 18:55:27)
    4. arrow from EP to EPG is not necessarily defined intentionally. (dconde, 18:56:20)
    5. this is an external referene to the group is belong. EP is NOT in the policy repostory. (dconde, 18:56:46)
    6. we need to separate metadata (dconde, 18:57:56)
    7. always ask the EP registry (as an index) (dconde, 18:58:28)
    8. renderers ought to subscribe by context (to be defined -- an enforcement domain) (dconde, 18:59:46)
    9. we are talking on definition of reactive vs. proactive. (dconde, 19:04:14)


Meeting ended at 19:04:28 UTC (full logs).

Action items

  1. we need to handoff to DATASTORE subgroup to have more detailed requirements. jmedved
  2. to modeling group to deal with directionality.
  3. is for readams and dvorkinista


Action items, by person

  1. jmedved
    1. we need to handoff to DATASTORE subgroup to have more detailed requirements. jmedved
  2. readams
    1. is for readams and dvorkinista


People present (lines said)

  1. dconde (99)
  2. alagalah (8)
  3. odl_meetbot (6)
  4. jmedved (5)
  5. raghu67 (5)
  6. hemanthravi (3)
  7. lenrow (2)
  8. tbachman (1)
  9. readams (1)
  10. mickey_spiegel (0)


Generated by MeetBot 0.1.4.