#opendaylight-meeting: MD-SAL meeting

Meeting started by edwarnicke at 16:05:00 UTC (full logs).

Meeting summary

    1. https://meetings.webex.com/collabs/#/meetings/detail?uuid=MCQK23GTHZNO7LDV6UWT6KLYPV-9VIB&rnd=497132.35684 (edwarnicke, 16:05:04)
    2. https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call (devinavery, 16:05:13)
    3. https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call (edwarnicke, 16:05:21)
    4. https://meetings.webex.com/collabs/#/meetings/detail?uuid=MCQK23GTHZNO7LDV6UWT6KLYPV-9VIB&rnd=497132.35684 (edwarnicke, 16:05:27)

  2. Weekly Status (edwarnicke, 16:05:36)
    1. https://git.opendaylight.org/gerrit/#/c/8046/ - Updates to DataBroker javadocs (edwarnicke, 16:09:47)
    2. https://git.opendaylight.org/gerrit/#/c/8168 - Updates to the toaster example to just the new DataBroker as documented (devinavery, 16:11:01)
    3. https://git.opendaylight.org/gerrit/#/q/project:controller+branch:master+topic:clustering,n,z - clustering patches (edwarnicke, 16:11:36)
    4. https://git.opendaylight.org/gerrit/#/c/8255/ Adding documentation to the opendaylight-invetory.yang file. (devinavery, 16:15:06)
    5. Colin raised possible future discussion about what you can understand from yang vs java (edwarnicke, 16:17:57)
    6. alagalah raised (potentially separable) question about what you can *do* from yang vs java (edwarnicke, 16:18:16)
    7. I think alagalah’s point was actually what *should be done* in Yang vs. Java, but all 3 are worth talking about (colindixon, 16:18:51)
    8. https://git.opendaylight.org/gerrit/#/q/message:XSQL,n,z - XSQL patches Sharon would like to present next week (edwarnicke, 16:20:49)

  3. Operational vs Config Datastores (devinavery, 16:23:36)
    1. Operational datastore is always a superset of the configuration datastore. (devinavery, 16:23:48)
    2. - apx 22 minutes in Ed is sharing screen which provides example of this (devinavery, 16:26:03)
    3. if you add the line "config false" to a property, it will exist only in the operational datastore (rgowrishankar, 16:26:04)
    4. Q: if you have a config attr called "port" how would you keep them in sync? Does MD-SAL provide this? Or is it the responsibility of the app? (devinavery, 16:30:59)
    5. A from Ed: It is the responsibility of the app - there is no way for MD-SAL to understand the operational attributes and how they are used. (devinavery, 16:31:49)
    6. A from Ed continue: The operational and config can be out of sync for a valid reason - you want something configured, but it couldn't be applied to operational correctly (devinavery, 16:32:54)
    7. Q from Colin: could we have good defaults like sync config to operational by default? (devinavery, 16:33:11)
    8. A from Ed: We need to explore the use-cases where sync from config to operational is desired. (devinavery, 16:33:32)
    9. Colin points out that config is the intent, and operational is the application of the intent. Colin suggests improving documentation to make this easier to understand and use. (devinavery, 16:34:37)
    10. Recommendation from Ramkumar - good improvement would be an easy way to correlate between the config and operational trees. For example, given node 1 in the config tree, get me the same node in the operational (devinavery, 16:35:56)
    11. From Tony - use the same instance identifier in the operational store to get the same information that you did from the config store (i.e. opendaylight-inventory:nodes/node/myCustomNode is the ID in both datastores (devinavery, 16:36:54)
    12. "A node has an address - It should have the same address in config and operational." (devinavery, 16:37:46)
    13. If lead Foo { config: false } is defined, then you can not put foo=5 into the config store (since it is an operational attribute) (devinavery, 16:40:28)
    14. examples of how I tend to represent nodes tersely (edwarnicke, 16:40:55)
    15. nodes->node[nodeId]- the node with nodeId (edwarnicke, 16:41:26)
    16. Are the stores enforcing the config false? (devinavery, 16:41:37)
    17. nodes->node[nodeId](flowcapable) -> tables -> table[tableId] - the table with tableId in a flowcapable augmented node with nodeId (edwarnicke, 16:42:12)
    18. no, The stores are not enforcing the config = false because the data stores for the binding aware enforce that. It complicates the case where people read from one store and writing to other and would complicate the binding aware logic (devinavery, 16:44:25)
    19. Question - what is a use case to copy from operational to config? A: Example - you query the switch for the current values and then write to the current config (which is stored in the operational) to the config (devinavery, 16:45:45)
    20. Q: If we are not going to enforce this flag, why do we even have the flag and confuse people? (devinavery, 16:46:54)
    21. A: Having two datastores makes sense to separate what the user wants for a config and what it actually comes as (example, MTU size) (devinavery, 16:49:28)
    22. Suggestion (POV) - ONLY the data read from the network should be written to operational (devinavery, 16:50:36)
    23. Further clarification. Operational is a feedback loop, providing information from the real world, and the config is the intent. (devinavery, 16:51:13)
    24. Some comments on phone suggest that we should have a config attribute and a separate operational attribute (devinavery, 16:53:14)
    25. Q: Should we enforce the config: false in the MD-SAL? some thoughts that we should enforce it (devinavery, 16:56:20)
    26. A: Sounds like general concensus that we should enforce this at the config datastore level (devinavery, 16:57:27)
    27. recommendation - suggestion that you just ignore the config attributes, or possible create an object which has a copy constructor in the java class (devinavery, 16:58:00)
    28. Need an enhancement to have the config store enforce this. (devinavery, 17:00:44)
    29. Suggestion that if someone writes operational data to config store it should be a hard fail (devinavery, 17:01:28)
    30. colindixon just wants to point out that he’s now confused about how we should use operational vs. config—some people are saying it’s intent vs. expression and others are saying that it’s user expressed data vs. measured data—and it’s sounding like this separation may more of a mechanism that can be used for different things and we should define common patters (colindixon, 17:01:30)


Meeting ended at 17:03:48 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. devinavery (31)
  2. colindixon (21)
  3. edwarnicke (17)
  4. alagalah (5)
  5. odl_meetbot (4)
  6. rgowrishankar (1)
  7. uchau (1)
  8. kw_ (1)


Generated by MeetBot 0.1.4.