#opendaylight-meeting: MD-SAL hackers

Meeting started by colindixon at 15:07:34 UTC (full logs).

Meeting summary

  1. agenda bashing (colindixon, 15:07:40)
    1. two topics are brought up: (1) usability discussions for MD-SAL in general and (2) possibly trying to identify sub-projects of controller (colindixon, 15:09:22)

  2. usability update (colindixon, 15:09:32)
    1. alagalah has started looking at the existing wiki links to help with the usability, and published his recommendations (see last week’s meeting minutes) (tbachman, 15:10:50)
    2. alagalah notes that this initiative started with the question of “how a newbie could get started with the MD-SAL, config subsystem, YANG, etc.” (colindixon, 15:11:00)
    3. goal is to have it be possible for somebody to get anything they need to know in six clicks on the wiki (colindixon, 15:11:31)
    4. alagalah says we need to annotate the yang a bit better (tbachman, 15:13:32)
    5. https://wiki.opendaylight.org/view/Meetings (dfarrell07, 15:14:21)
    6. tpatellis says that going through explaining the config system to alagalah revealed how difficult it is to explain the config system to new folks (tbachman, 15:15:11)
    7. tpatellis notes that this wasn’t discussed at the dev summit; we could try to document it, but it’s still difficult to consume (tbachman, 15:16:33)
    8. jmedved says that John Burns (?) should be helping with this process (tbachman, 15:18:41)
    9. colindixon notes that there’s no obvious entry point on the wiki on how to on-board with this stuff (tbachman, 15:19:20)
    10. colindixon also notes that there are several “eras” of the MD-SAL documentation, which makes this more confusing (tbachman, 15:19:48)
    11. colindixon recommends adding things like “this is out of date” to pages that are no longer relevant. (tbachman, 15:20:22)
    12. jmedved asks how we can remove content (tbachman, 15:20:41)
    13. colindixon says he hates to remove content — would prefer just indicating that the content is old (tbachman, 15:21:01)
    14. jmedved says we should make clear that the config system and MD-SAL are two different components (tbachman, 15:22:40)
    15. colindixon says we need to break up the MD-SAL documentation (i.e. two people working for two weeks isn’t sufficient) (tbachman, 15:23:12)
    16. ACTION: alagalah says that he’ll take his recommmendations/links from last weeks, and stuff from tpatellis, and publish a list of concrete things that need to happen using bugzilla (tbachman, 15:24:35)
    17. jmedved notes that even with documentation, it’s still difficult to use, and asks what else we can do to improve the learning curve (tbachman, 15:25:39)
    18. alagalah says that there are a number of folks who have the “tribal knowledge”, who could investigate writing stuff up on their speciality. (tbachman, 15:26:12)
    19. jmedved says that rovarga_ ttkacik, and tpatellis are on the call, and wonders if we can assign each of them an action to identify the gaps we currently have for better usability by next week (tbachman, 15:28:22)
    20. tpatellis says he can identify the pain points, but not yet solutions (tbachman, 15:29:02)
    21. alagalah will also provide his pain points (tbachman, 15:29:18)
    22. ACTION: alagalah to come up with his list of adoption pain points by next meeting (alagalah, 15:30:11)
    23. ACTION: alagalah to take what he has done so far on the documentation front and break it into chunks (alagalah, 15:30:31)
    24. ACTION: colindixon to send e-mail noting his pain points: (1) it’s hard to figure out how to take the yang file for the config subsystem and translate it into an XML file, and (2) the config yang file is compiled in a different way than yangtools does (colindixon, 15:33:47)
    25. colindixon says that config subsystem probably causes the largest amount of difficulty, but is probably encoutered less often than RPCs and notifications, which may affect what we prioritize as far as documentation (tbachman, 15:36:39)
    26. uchau asks if the config subsystem is just a “recommended thing to use”, or if it’s really a requirement (tbachman, 15:37:46)
    27. colindixon says it would be hard for us to mandate using the config subsystem (tbachman, 15:38:50)
    28. colindixon says that the config subsystem enforces loading order within config subsystem components, but is a separate loading system than OSGI (tbachman, 15:39:48)
    29. jmedved says that for a system integrator, having a uniform way of managing the components is critical, and therefore we should adopt some conventions on how these things are done (tbachman, 15:43:31)
    30. rovarga_ says we could create a shim layer on top of the config system, reducing the use cases, to simplify the APIs and concepts, simplifying the user’s interaction with it (tbachman, 15:45:10)
    31. ACTION: rovarga_ to write an email describing why the things in the config subsystem are the way they are (tbachman, 15:46:46)
    32. colindixon asks why the config subsystem is necessary to do clustering (will also go read last week’s meeting minutes, as this was covered there) (tbachman, 15:49:06)
    33. tpatellis says that the config subsystem could be used as a mechanism for bringing apps down and back up when critical pieces like the data store fail (tbachman, 15:51:35)
    34. rovarga_ says that trying to understand the dependency graph in something like OSGI is challenging if not impossible, whereas the config subsystem provides some constructs to understand this (tbachman, 15:52:26)
    35. alagalah says that we need to provide background on all the pieces for ODL (config subsystem, MD-SAL, karaf, etc.) — not just background and how to use them, but when and why. (tbachman, 15:54:35)
    36. colindixon says there are probably different categories of users that we want to target this towards (i.e. depends on knowledge and use case) (tbachman, 15:55:14)
    37. colindixon believes that whatever we select as the priority, it’s probably best to use an “all-hands-on-deck” approach in order to get good documentation (tbachman, 15:58:45)
    38. colindixon asks if folks can pick up an item on the list that alagalah publishes, and indicate that they’ve picked it up (tbachman, 16:00:30)
    39. ACTION: keith send out a list of things to do; if people have cycles, pick up the item on the list a nd run with it (jmedved, 16:00:35)
    40. ACTION: tom p: list painpoints (jmedved, 16:00:48)
    41. ACTION: alagalah send out a list of things to do; if people have cycles, pick up the item on the list a nd run with it (alagalah, 16:01:06)
    42. ACTION: alagalah to send out a list of things to do; if people have cycles, pick up the item on the list and run with it (tbachman, 16:01:07)
    43. ACTION: tpatellis to provide a list of pain points (tbachman, 16:01:19)
    44. ACTION: robert varga: email with background design info on configu subsystem (jmedved, 16:01:21)
    45. ACTION: robert v: couple of imprvoement/simplification proposal -email (jmedved, 16:01:48)
    46. ACTION: rovarga_ email with background design info on configu subsystem (tbachman, 16:01:49)
    47. ACTION: couple of imprvoement/simplification proposal -email (tbachman, 16:02:07)
    48. ACTION: jmedved to start background architecture wiki using keith’s documentation (tbachman, 16:02:40)
    49. ACTION: jmedved start architecture section for config subsystem on wiki (jmedved, 16:03:47)
    50. ACTION: jmedved start architecture section for config subsystem on wiki (tbachman, 16:04:02)
    51. ACTION: uyen collect pain points from hp folks and send to keith (jmedved, 16:04:20)
    52. ACTION: uchau collect pain points from hp folks and send to keith (tbachman, 16:04:30)
    53. all action items sent to keith, copied folks on the call (jmedved, 16:04:34)


Meeting ended at 16:04:37 UTC (full logs).

Action items

  1. alagalah says that he’ll take his recommmendations/links from last weeks, and stuff from tpatellis, and publish a list of concrete things that need to happen using bugzilla
  2. alagalah to come up with his list of adoption pain points by next meeting
  3. alagalah to take what he has done so far on the documentation front and break it into chunks
  4. colindixon to send e-mail noting his pain points: (1) it’s hard to figure out how to take the yang file for the config subsystem and translate it into an XML file, and (2) the config yang file is compiled in a different way than yangtools does
  5. rovarga_ to write an email describing why the things in the config subsystem are the way they are
  6. keith send out a list of things to do; if people have cycles, pick up the item on the list a nd run with it
  7. tom p: list painpoints
  8. alagalah send out a list of things to do; if people have cycles, pick up the item on the list a nd run with it
  9. alagalah to send out a list of things to do; if people have cycles, pick up the item on the list and run with it
  10. tpatellis to provide a list of pain points
  11. robert varga: email with background design info on configu subsystem
  12. robert v: couple of imprvoement/simplification proposal -email
  13. rovarga_ email with background design info on configu subsystem
  14. couple of imprvoement/simplification proposal -email
  15. jmedved to start background architecture wiki using keith’s documentation
  16. jmedved start architecture section for config subsystem on wiki
  17. jmedved start architecture section for config subsystem on wiki
  18. uyen collect pain points from hp folks and send to keith
  19. uchau collect pain points from hp folks and send to keith


Action items, by person

  1. alagalah
    1. alagalah says that he’ll take his recommmendations/links from last weeks, and stuff from tpatellis, and publish a list of concrete things that need to happen using bugzilla
    2. alagalah to come up with his list of adoption pain points by next meeting
    3. alagalah to take what he has done so far on the documentation front and break it into chunks
    4. alagalah send out a list of things to do; if people have cycles, pick up the item on the list a nd run with it
    5. alagalah to send out a list of things to do; if people have cycles, pick up the item on the list and run with it
  2. colindixon
    1. colindixon to send e-mail noting his pain points: (1) it’s hard to figure out how to take the yang file for the config subsystem and translate it into an XML file, and (2) the config yang file is compiled in a different way than yangtools does
  3. jmedved
    1. jmedved to start background architecture wiki using keith’s documentation
    2. jmedved start architecture section for config subsystem on wiki
    3. jmedved start architecture section for config subsystem on wiki
  4. UNASSIGNED
    1. rovarga_ to write an email describing why the things in the config subsystem are the way they are
    2. keith send out a list of things to do; if people have cycles, pick up the item on the list a nd run with it
    3. tom p: list painpoints
    4. tpatellis to provide a list of pain points
    5. robert varga: email with background design info on configu subsystem
    6. robert v: couple of imprvoement/simplification proposal -email
    7. rovarga_ email with background design info on configu subsystem
    8. couple of imprvoement/simplification proposal -email
    9. uyen collect pain points from hp folks and send to keith
    10. uchau collect pain points from hp folks and send to keith


People present (lines said)

  1. tbachman (60)
  2. colindixon (14)
  3. alagalah (13)
  4. jmedved (7)
  5. dfarrell07 (7)
  6. odl_meetbot (5)


Generated by MeetBot 0.1.4.