#opendaylight-meeting: MD-SAL interest call

Meeting started by devinavery at 16:01:17 UTC (full logs).

Meeting summary

    1. devinavery says last week we discussed doing a review of changes in the works, in order to keep track of what’s going on as well as bring others into the conversation (tbachman, 16:06:21)
    2. https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call Weekly call, with agenda (tbachman, 16:07:01)
    3. https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Queries shows changes to the controller (tbachman, 16:07:42)
    4. edwarnicke asks if there’s a way to remove “excessively stale” patches (tbachman, 16:07:54)
    5. devinavery says we could add some constraint, such as older than 30 days (tbachman, 16:08:08)
    6. devinavery says the first goal is to get a sense of what changes are going into the controller core (tbachman, 16:08:57)
    7. devinavery asks if there are any other projects besides controller and yangtools that are needed (tbachman, 16:09:24)
    8. colindixon says we could add AAA (tbachman, 16:09:53)
    9. edwarnicke says he’s a bit concerned about scope creeping beyond the capacity to influence (e.g. we may not have any AAA committers here) (tbachman, 16:10:33)
    10. colindixon says that’s where we may want to intentionally increase the scope (tbachman, 16:10:49)
    11. edwarnicke says at some point this stops becoming just an MD-SAL call, and is a different call (not a bad thing, just different) (tbachman, 16:11:17)
    12. devinavery says we may also want to collect NETCONF and MD-SAL breakouts here (tbachman, 16:11:52)
    13. devinavery says one example was in Helium, POSTing on RESTCONF wouldn’t wait for the data store (tbachman, 16:13:32)
    14. devinavery says in yangtools, the orderby clause was broken for SFC, which was fixed (tbachman, 16:14:20)
    15. colindixon asks about the ordered by fix (tbachman, 16:14:41)
    16. ttkacik says the orderedby statement is honored by the data store, but the problem is that configuration data requires you to have a key (tbachman, 16:15:33)
    17. ttkacik says the orderedby was to show that the data was reordered after the PUT (tbachman, 16:15:52)
    18. ttkacik says the MD-SAL will use less-efficient data structures, but will preserve the ordering (tbachman, 16:16:09)
    19. colindixon asks why it’s less efficient (tbachman, 16:16:16)
    20. rovarga says simply b/c you have to use a linked hashmap and not a hashmap — you need an iterable collection that guides the iteration ordered (tbachman, 16:16:45)
    21. colindixon says you need one extra pointer per object — it’s about a 2% hit (tbachman, 16:17:02)
    22. rovarga says there are no just pointers in java, so it has to go somewhere (objects have a minimum size of 12 bytes); with collections that are millions of entries long, this makes a differenc (tbachman, 16:17:33)
    23. rovarga says if you say a particular list is ordered by, then a different backing class is used to store those entries — a linked hash map (tbachman, 16:18:35)
    24. rovarga says a trie or hash map won’t preserve the order (tbachman, 16:18:49)
    25. discussing patch size - do we have any experience on how many lines is too many (devinavery, 16:27:29)
    26. no consensus on if line counts are useful or not... (devinavery, 16:28:34)
    27. ttkacik says they aren’t one-to-one — multiple patch sets can be attached to the bug (tbachman, 16:28:58)
    28. proposal that bug should have a bug in "large line count" patches (devinavery, 16:29:03)
    29. devinavery asks if it’s fair to say that even if it’s the same bug ID, it’s a bug ID in the commit message — is it fair to say we encourage this in bug commit messages? (tbachman, 16:29:44)
    30. edwarnicke says it’s a good idea to have bug IDs in commit messages in general (tbachman, 16:30:03)
    31. edwarnicke asks what is the purpose of the attaching bug (tbachman, 16:30:22)
    32. ttkacik says there are two types: some that are mostly about the functionality, which should have bugs attached; and others that only deal with source code quality (tbachman, 16:31:02)
    33. ttkacik says it doesn’t make sense to create bugs for the small issues (tbachman, 16:31:12)
    34. rovarga seconds that — recalls a number of “drive-by’s” like this. Isn’t sure that forcing this for all patches isn’t the right way (tbachman, 16:31:49)
    35. edwarnicke says sonar has been very useful — encourages folks to go to sonar and start working through the code-quality complaints (tbachman, 16:32:26)
    36. colindixon says we’re looking for things that help us in practice, that are “probably should” guidelines (tbachman, 16:33:16)
    37. devinavery says if we’re changing functionality, a bug should exist — helps us understand the old behavior, desired behavior, and potentially how we’re going to fix it — asks if anyone objects to this (tbachman, 16:33:48)
    38. devinavery says it’s up to the committers to see if they understand the reason behind the change — if they don’t understand why it’s necessary, they can request more information, and this is where a bug is helpful (tbachman, 16:34:44)
    39. rovarga says you have to be careful with that guidance (tbachman, 16:35:01)
    40. devinavery says part of the goal is to have others besides committers review the code — the committers also need to ensure the rest of the community understands what’s changing (tbachman, 16:35:35)
    41. rovarga says explaining things to the general public means that if someone doesn’t get it, you can’t merge the change — have to be careful with these kinds of statements (tbachman, 16:36:08)
    42. edwarnicke says he believes devinavery is saying something different — he’s saying that it’s helpful to us to grow the community if we make some effort to help others who are trying to get involved (tbachman, 16:36:35)
    43. devinavery says yes — also a historical dimension to this — helps folks who come later to understand (tbachman, 16:36:56)
    44. devinavery says that’s one of the reasons for a bug — isn’t to gate the merge, but to help people understand them (tbachman, 16:37:35)
    45. rovarga says he’d encourage using better commit messages first, then using bugs (tbachman, 16:37:48)
    46. devinavery says yes — the commit message is important; but bug IDs can help as a reference for very long descriptions that aren’t appropriate for commit messages (tbachman, 16:38:29)
    47. edwarnicke asks if there are known outstanding issues with restconf — is interested in moving with the clustering switchover (tbachman, 16:43:40)
    48. ttkacik says he needs to verify his patch fixes the downstream projects (tbachman, 16:43:51)
    49. edwarnicke asks if we’ve come up with a smarter way of informing folks of changes of this nature (tbachman, 16:44:10)
    50. devinavery says we may have to follow up on this in a subsequent call (tbachman, 16:44:52)
    51. ttkacik says the patches for Bug 2362 changes constraints validation from compulsory to optional (tbachman, 16:46:13)
    52. colindixon says if this is going to slow controller down by 3-4 weeks, then we can talk about this (tbachman, 16:47:10)
    53. edwarnicke asks if there’s a more effective way of communicating changes that break everything (tbachman, 16:48:35)
    54. colindixon says no, but he feels the right approach is to have both a static place to log them, and email release, and cross-link the two (tbachman, 16:49:21)
    55. colindixon says he has an email (either already sent, or in his outbox) on this topic (tbachman, 16:49:49)
    56. devinavery says next week will be a presentation on the message bus (tbachman, 16:50:28)


Meeting ended at 16:50:32 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (64)
  2. devinavery (6)
  3. odl_meetbot (4)


Generated by MeetBot 0.1.4.