#opendaylight-group-policy: datastore

Meeting started by regXboi at 14:02:56 UTC (full logs).

Meeting summary

    1. https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.e7ngfp46nqhv5oltibelval6o8?authuser=1 (regXboi, 14:03:27)
    2. link is the google hangout (regXboi, 14:03:39)

  2. general chit chat about our various weekend adventures (alagalah, 14:04:31)
    1. regXboi Didn't get shark-nado'd so we are happy (alagalah, 14:04:45)

  3. Jan presenting on Datastore with Akka et al (alagalah, 14:05:04)
    1. discussion of datastore implementation based on APIC/Akka (regXboi, 14:05:18)
    2. distributed data store wiki link below (regXboi, 14:06:03)
    3. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store (regXboi, 14:06:44)
    4. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Rough_requirements_for_Helium <- what it says it is (regXboi, 14:07:48)
    5. question on requirements #2 and #3 - is replication the responsibility of the data store or the persistence layer? (regXboi, 14:09:09)
    6. question from alagalah about if sharding is following the model where the service is co-located with its data (regXboi, 14:10:15)
    7. answer: that is the intent, but it is not clear if specifying co-location is possible via RESTCONF (regXboi, 14:10:44)
    8. alagalah satisfied, letting go of the bone (alagalah, 14:11:15)
    9. jmedved elaborated that the idea was to have a pluggable policy for apps to use the datastore (regXboi, 14:11:19)
    10. and for helium, the likely implementation will mimic APIC (regXboi, 14:11:33)
    11. regXboi asks re: requirements 2,3 from above link, who is responsible for replication. (alagalah, 14:12:47)
    12. moiz responds that it's the datastore's responsibility. Is going to share persistent object from primary to slaves via Akka. (alagalah, 14:13:22)
    13. regXboi asks if primary is only area of persistence (implying replicas are in memory) but moiz points out that replicas will be persistent too. (alagalah, 14:14:14)
    14. regXboi tabling replication concern for later in the discussion (regXboi, 14:16:05)
    15. https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.e7ngfp46nqhv5oltibelval6o8?authuser=1 (tbachman, 14:16:20)
    16. https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.e7ngfp46nqhv5oltibelval6o8?authuser=1 link to hangout (tbachman, 14:16:45)
    17. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store link to data store on ODL wiki (tbachman, 14:17:26)
    18. question about requirement #4 - how does lack of distributed transactions bounce against the common tenant (regXboi, 14:19:52)
    19. ACTION: mike to answer the above info question on transcation vs common tenant storage (regXboi, 14:20:23)
    20. some more discussion about distributed transactions and how to make them more easy to implement (regXboi, 14:22:29)
    21. regXboi claims that number 5 in the requirement list is a MUST not a should, as it is absolutely necessary for audit. (regXboi, 14:24:22)
    22. question for raghu67_ about data size (regXboi, 14:25:08)
    23. https://wiki.opendaylight.org/view/Group_Policy:Scaling (regXboi, 14:26:20)
    24. jmedved to know what of that link is applicable to helium and also which repositories each number applies to... (regXboi, 14:26:52)
    25. ACTION: regXboi to take another pass through the above link and add the information jmedved is asking for (regXboi, 14:27:50)
    26. discussing design principles (regXboi, 14:29:19)
    27. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#General_Design_Principles (regXboi, 14:29:31)
    28. ACTION: alagalah to work with GBP team to add tasks to plan to test how we can integrate with Clustered/Sharded Data yet still develop to existing InMemory data store in the interim (in case they are not drop/replace perfectly) (alagalah, 14:29:39)
    29. regXboi asks about the ability to reconfigure the sharding structure (ie via JSON call) whilst the controller is running or does it require taking the cluster down, config, bring up (alagalah, 14:37:41)
    30. jmedved et al reply that it is an outstanding question they have considered. alagalah suggests for Helium we require taking down the cluster so we don't have to deal with consistency during re-config and shoot for something more dynamic in Lithium (alagalah, 14:38:24)
    31. regXboi suggests that for Helium we build in the RESTCONF API that lets us reconfig dynamically but return "501" ie. its extensible but not implemented. (alagalah, 14:39:02)
    32. jmedved clarifies that it may not be "RESTCONF" but more and API but in generalisation yes, extensible but not implemented to Helium is agreed upon (alagalah, 14:39:34)
    33. AGREED: Dynamic configuration of the sharding structure will be stubbed but not implemented for Helium. For Helium controller down will be required. (alagalah, 14:40:03)
    34. question on whether shard placement should be pluggable or not (regXboi, 14:41:50)
    35. regXboi answers that it should be pluggable, but doesn't have to be in Helium time frame (regXboi, 14:42:17)
    36. proposal that a tool be created to allow for shard placement (regXboi, 14:43:35)
    37. subtopic: why akka (regXboi, 14:44:08)
    38. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Akka (regXboi, 14:44:19)
    39. discussion of remoting, clustering and persistence from Akka (regXboi, 14:45:29)
    40. ACTION: regXboi to read wiki page and put questions to the mailing list (regXboi, 14:48:25)
    41. ACTION: next datastore meeting to be webex and continue discussion (regXboi, 14:48:51)
    42. proposal to go on a faster cadence next week to unblock implementation (regXboi, 14:49:14)
    43. couple the faster cadence with email to see what progress we can make : further discussion to go off line (regXboi, 14:52:05)
    44. due to remaining time, jumping to PoC items (regXboi, 14:52:23)
    45. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Proof_of_Concept (regXboi, 14:52:36)
    46. regXboi pleas to others to read and comment on mailing list... (regXboi, 14:53:42)
    47. regXboi suggests that we are able to dump the keys and build indexes around that, but to do "APIC" style query we would need to search via attribute. (alagalah, 14:56:24)
    48. context of above comment was on querying the DOM tree of the datastore (regXboi, 14:56:44)
    49. the issue here is how to support searching by value attribute without changing the existing data related API (regXboi, 14:57:16)
    50. I think we should be able to layer the attribute value based query API on top of the current API (raghu67_, 14:58:08)
    51. regXboi points out on "query like filters" that there is an intern project pointed at this that *may* be leveragable (regXboi, 14:58:14)
    52. alagalah asks if the SB plugins haven't already solved the serialization problem? (regXboi, 15:00:15)
    53. jmedved and moiz answer that this is a different problem (regXboi, 15:00:36)
    54. this is serialization of the Akka messages themselves for communication to remote Akka instances (regXboi, 15:01:27)
    55. regXboi asks for mail to the list clarifying the data validation concept (regXboi, 15:03:25)


Meeting ended at 15:03:37 UTC (full logs).

Action items

  1. mike to answer the above info question on transcation vs common tenant storage
  2. regXboi to take another pass through the above link and add the information jmedved is asking for
  3. alagalah to work with GBP team to add tasks to plan to test how we can integrate with Clustered/Sharded Data yet still develop to existing InMemory data store in the interim (in case they are not drop/replace perfectly)
  4. regXboi to read wiki page and put questions to the mailing list
  5. next datastore meeting to be webex and continue discussion


Action items, by person

  1. alagalah
    1. alagalah to work with GBP team to add tasks to plan to test how we can integrate with Clustered/Sharded Data yet still develop to existing InMemory data store in the interim (in case they are not drop/replace perfectly)
  2. jmedved
    1. regXboi to take another pass through the above link and add the information jmedved is asking for
  3. regXboi
    1. regXboi to take another pass through the above link and add the information jmedved is asking for
    2. regXboi to read wiki page and put questions to the mailing list
  4. UNASSIGNED
    1. mike to answer the above info question on transcation vs common tenant storage
    2. next datastore meeting to be webex and continue discussion


People present (lines said)

  1. regXboi (48)
  2. alagalah (26)
  3. tbachman (5)
  4. odl_meetbot (4)
  5. hemanthravi (3)
  6. jmedved (1)
  7. raghu67_ (1)


Generated by MeetBot 0.1.4.