#opendaylight-meeting: kernel projects

Meeting started by rgoulding at 16:58:43 UTC (full logs).

Meeting summary

  1. agenda bashing (rgoulding, 16:58:53)
    1. https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018 (rgoulding, 16:59:00)
    2. AsyncWriteTransaction submit() with @CheckReturnValue (rgoulding, 16:59:07)

  2. BigBumpOfJan2018 (rgoulding, 17:04:07)
    1. https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018 (rgoulding, 17:04:17)
    2. kernel patches have been updated already (rgoulding, 17:07:17)
    3. many of the others including netvirt, infrautils, genius, etc. have been updated to use 3.0.2 (rgoulding, 17:07:32)
    4. more testing is needed (rgoulding, 17:07:37)
    5. other patches need to be ammended to utilize 3.0.2 instead of 3.0.2-SNAPSHOT (rgoulding, 17:08:26)
    6. skitt, if CSIT passes and results aren’t too scary, perhaps that is enough to get releng to merge them? (rgoulding, 17:10:56)
    7. the initial plan was to kick everyone out and then bring back in (rgoulding, 17:11:08)
    8. Thursday TSC call will make the call whether to go/no-go (rgoulding, 17:11:16)
    9. rovarga says it might be better to just do it one by one (rgoulding, 17:12:22)
    10. i.e., wait until one merge job finishes and publishes artifacts, then recheck the next, and so-on (rgoulding, 17:12:42)
    11. Will 3.0.2 be the final version? (rgoulding, 17:18:41)
    12. the opinion is that this is the version we will release with unless we find something that requries a new revision (rgoulding, 17:18:56)
    13. if we do need a new version, we should be able to do this easier by just bumping the version to 3.0.3 in integration/distribution and inheriting the newer version in the runtime since we use version ranges (rgoulding, 17:19:46)
    14. rovarga if this transition is smooth and done in a reasonable timeframe, then we can discuss whether it makes sense to roll out 2.0.1 of yangtools to get the fixes in that (rgoulding, 17:21:01)
    15. if not, we will just punt to SR1 and be done (rgoulding, 17:21:19)
    16. vorburger states that the timeline is tight (rgoulding, 17:31:44)
    17. LuisGomez says that there will need to be a patch to remove non-tested patches (rgoulding, 17:32:21)
    18. vorburger is there a fallback plan? (rgoulding, 17:32:35)
    19. skitt the fallback would be odlparent 2.0.6 and what would be the case in yangtools? (rgoulding, 17:32:54)
    20. rovarga only option would be to use yangtools 1.2.1 which was used in Nitrogen SR1 (rgoulding, 17:33:14)
    21. skitt what would the consequences of that be to end users in oxygen? (rgoulding, 17:33:36)
    22. rovarga there is a clustering bug reported in live environments that could not be fixed without yangtools 2.0.0 (rgoulding, 17:34:00)
    23. related to running clusters across timezones (rgoulding, 17:34:07)
    24. it would be painful for downstreams (rgoulding, 17:34:18)
    25. the expectation is that fallout from this will be minor, since a lot of unit tests are passing (rgoulding, 17:35:33)
    26. vorburger states that it now takes much much longer to make changes in odlparent now to get changes in (rgoulding, 17:37:50)
    27. rovarga you either get isolation or integratability (rgoulding, 17:38:02)
    28. there isn’t really a middle ground (rgoulding, 17:38:07)
    29. rovarga at some point the core needs to stop churning releases and pushing on downstreams to track them (rgoulding, 17:38:55)
    30. vorburger doesn’t have a solution persay, but he does wnat to point out that it takes a long time to fix even small things. Things have slowed down to integrate things in odlparent (rgoulding, 17:39:23)
    31. vorburger asks if there are better solutions? (rgoulding, 17:39:31)
    32. skitt there is friction that arises since upgrades all have different constraints. for example, we could fix bugs quickly in karaf and only bump affected downstream projects. But since we have everything bunched together, it is more involved to adapt. The advantage to version ranges is that we could achieve a lot of this much more quickly (rgoulding, 17:41:37)
    33. perhaps we will need to split odlparent up somehow (rgoulding, 17:41:45)
    34. skitt regarding development velocity there is some rule / best practice (written down somewhere) stating we develop things in a downstream and then once it becomes more useful we push it up. if you stick to that then assuming nothing upstream blocks you, then you can still have good velcoity. Starting things where they will ultimately end up (i.e., odlparent), that will slow you down. (rgoulding, 17:43:14)
    35. the idea is to start local, then move upwards (rgoulding, 17:43:33)
    36. rovarga not sure if we will be able to make version ranges completely work (rgoulding, 17:43:59)
    37. rovaraga what if we bump to karaf to 4.1.4 in odlparent 3.0.3, which also bumps jetty then what happens in the various situations? (rgoulding, 17:44:25)
    38. i.e., jetty causes incompatibilities but karaf doesnt (rgoulding, 17:44:33)
    39. other projects have stated they arent really doing semver (netty) (rgoulding, 17:45:03)
    40. some upstreams don’t necessarily comply to non-breaking API changes, whcih makes it particularly hard to upgrade (rgoulding, 17:45:36)
    41. there is a lot of work that could be done on the odlparent side that could be done to pre-validate, but that might be more useful in int/dist (rgoulding, 17:45:51)
    42. skitt for checkstyle, we should have checkstyle snippets to get to the point where only certain parts can be enforced in downstreams as opposted to all or none (rgoulding, 17:46:25)
    43. skitt temporarily, we could have different projects using different versions of odlparent (rgoulding, 17:46:48)
    44. i.e., if there is somethign missing in the karaf configuration (rgoulding, 17:47:09)
    45. skitt points out that this means being very careful about what is merged to odlparent (rgoulding, 17:47:43)
    46. rovarga, which runs contratry to quicker velocity desires (rgoulding, 17:47:59)
    47. run continuous deployment will allow us to see an automated scripted release with each patch. We don’t have all the scripting or build infra to get there yet. (rgoulding, 17:48:38)
    48. the distribution-check does some of this, but it depends on autorelease (rgoulding, 17:49:06)
    49. LuisGomez something we are missing for sure is an autorelease job that builds all the projects with latest version of odlparent/yangtools to produce some distribution that we can pass to CSIT (rgoulding, 17:52:21)
    50. https://jira.opendaylight.org/projects/RELENG/issues/RELENG-69 (LuisGomez, 17:52:43)
    51. rovarga it should be spinning a release for each project in the dependency order, and running CSIT against the staged artifacts, and if the projects CSIT passes, then it should be good to release (rgoulding, 17:53:19)
    52. rovarga the thing is that if it is autorelease, then it takes half a day and any sort of glitch or failure is a show stopper for seeing useful results (rgoulding, 17:54:25)
    53. LuisGomez this may be too expensive though (per project) (rgoulding, 17:56:09)
    54. LuisGomez there will be a lot of infra load. Maybe it makes more sense to do it with one particular case (i.e., netvirt which has a lot of CSIT) then we have some confidence of whether the change is good (rgoulding, 17:56:55)

  3. AsyncWriteTransaction submit() with @CheckReturnValue (rgoulding, 17:57:46)
    1. https://git.opendaylight.org/gerrit/#/c/66360/ (rgoulding, 17:57:59)
    2. https://git.opendaylight.org/gerrit/#/c/66361/ (rgoulding, 17:58:11)
    3. tpantelis this is an API change and we are beyond API freeze now (rgoulding, 17:58:45)
    4. API freeze is not only an ODL internal thing, but also the downstreams that we don’t know about (rgoulding, 17:59:47)
    5. while it gives us a feeling of what it will do andaffect in our own release, it doesn’t address the fact that we dont’ know what is happening downstream (rgoulding, 18:00:06)

  4. slf4j code quality checks with checkstyle-odl-checks VS findbugs-slf4j.. because of Eclipse IDE integration issue, I propose to: (rgoulding, 18:02:04)
    1. https://git.opendaylight.org/gerrit/#/c/66449/ (rgoulding, 18:02:16)
    2. compare the checks that are provided by both (rgoulding, 18:03:37)
    3. rovarga doesn’t want to get rid of the checkstyle ones if they add anything on top of findbugs one (rgoulding, 18:04:56)
    4. we can keep in cs too (rgoulding, 18:05:02)
    5. vorburger is much less motivated to get the CS patches in (rgoulding, 18:05:16)

  5. FYI error-prone now adopted in infrautils, with custom tuned config. If time, may try to use infrautils parent e.g. in genius. (rgoulding, 18:07:25)
    1. vorburger spent time to tune a config for this and has switched infrautils to enforce (rgoulding, 18:07:54)
    2. rovarga enabling error-prone breaks some valid code (rgoulding, 18:10:12)
    3. rovarga something with type inferences/generics (rgoulding, 18:10:20)
    4. vorburger this project is very active and what might have broken in the past might be fixed now (rgoulding, 18:10:41)


Meeting ended at 18:13:03 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. rgoulding (78)
  2. odl_meetbot (3)
  3. LuisGomez (1)
  4. vorburger (1)


Generated by MeetBot 0.1.4.