#opendaylight-group-policy: GBP datastore

Meeting summary

1. agenda bashing (regXboi, 14:03:18)
   1. only agenda item I have is new DC numbers at link below (regXboi, 14:03:36)
   2. https://wiki.opendaylight.org/view/Group_Policy:Scaling (regXboi, 14:03:46)
   3. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store (raghu67, 14:05:26)
   4. raghu67 asks about what we're calling resolvers in the use cases (tbachman, 14:09:36)
   5. regXboi says the renderer takes all the particulars of the model, and renders it into the particular configuration language needed by the resolver (tbachman, 14:10:45)
   6. the resolve operation should be a local operation in most cases. (tbachman, 14:10:55)
   7. the only time it isn't local is when the operation is completely out of scope, in which case it goes back to the renderer for resolution. If not resolvable by the renderer, this leads to an exception path (tbachman, 14:11:36)
   8. regXboi believes we need the inventory of resolvers for the exception path -- hopes it's part of ODL's inventory. (tbachman, 14:12:18)
   9. This leads to the question of how big the inventory in ODL can be/gets (tbachman, 14:12:37)
   10. Moiz continues data store presentation (tbachman, 14:22:15)
   11. regXboi wants to make sure that we have architectural white space for auditing (tbachman, 14:22:39)
   12. Moiz says we can either use logging or a separate monitoring application for this. (tbachman, 14:23:02)
   13. regXboi claims that logging is not auditing (tbachman, 14:23:21)
   14. in the case of audit, want to know who did it, what authority that had to do it, and arguments provided so that a reply can be performed. (tbachman, 14:24:52)
   15. jumping down to call diagrams (regXboi, 14:28:12)
   16. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Creating_a_new_transaction (regXboi, 14:28:36)
   17. raghu67 asks whether we need to support distributed transactions across shards. alagalah says he doesn't believe we do. (tbachman, 14:31:45)
   18. alagalah asks whether the operations are synchronous for all shards (tbachman, 14:32:09)
   19. Moiz says that it's asynchronous, with the "ask" getting a future which can be called later (tbachman, 14:32:51)
   20. readams notes that there currently aren't any semantics for things like rollbacks in the current data store APIs (tbachman, 14:35:13)
   21. readams noticed that the change notifications API might be a bit broken, when considering a multi-thread context. For example, are notifications guaranteed to be dispatched from a single thread? (tbachman, 14:41:05)
   22. raghu67 notes that some interfaces pass entire subtrees, which can be expensive. (tbachman, 14:41:43)
   23. current commits are from a single thread, which may create performance issues later on (regXboi, 14:41:59)
   24. point that failed transaction objects are expected to be thrown away and a new transaction object allocated (regXboi, 14:42:32)
   25. discussion of better documentation and examples (and fixed code) and possibly fix API... (regXboi, 14:50:22)
   26. no meeting next week due to the holidy (tbachman, 15:02:48)

Action items

1. (none)

People present (lines said)

1. tbachman (19)
2. regXboi (12)
3. alagalah (6)
4. odl_meetbot (4)
5. raghu67 (2)