#opendaylight-meeting: tws

Meeting summary

1. agenda (tbachman, 18:01:00)
   
2. How to get started with JJB (tbachman, 18:02:11)
   1. https://wiki.opendaylight.org/view/RelEng:Jenkins releng jenkins page (tbachman, 18:03:51)
   2. the default tab shows the daily jobs (tbachman, 18:04:07)
   3. most jobs use the dynamic verify slave, which is an EL6 slave JDK7 and 8 available for builds (tbachman, 18:04:29)
   4. if you just want the basic job templates, no extra action is needed once you’re set up in JJB (tbachman, 18:05:03)
   5. If you need to test JJB, you can pull it from zxiiro’s repo to test locally before pushing (only needed if you plan on using the LF sandbox) (tbachman, 18:05:40)
   6. all projects get a verify, merge, daily, integration, and sonar job (tbachman, 18:06:03)
   7. in gerrit, you can use the keywords recheck or remerge, and it will cause the jobs to be retriggered by the patch (tbachman, 18:06:29)
   8. you can run python scripts/jjb-init-project.py <name of project> to generate the demo file that defines all the jobs for your project (tbachman, 18:07:24)
   9. you can push that to releng and add zxiiro and tykeal as reviewers (tbachman, 18:07:35)
   10. There are some customizations that can be done (see wiki) (tbachman, 18:07:50)
   11. also add the project lead as a reviewer for the releng patch (tbachman, 18:08:46)
   12. If any default options are overridden, the script creates a config file for your project (tbachman, 18:11:07)
   13. flaviof asks what happens to the existing silo once a project transitions to JJB (tbachman, 18:13:27)
   14. zxiiro recommends disabling at least the existing merge job to prevent two silos merging the same artifacts (tbachman, 18:13:51)
   15. edwarnicke says he disables the silos and retriggers jobs to test the JJB configuration (tbachman, 18:14:25)
   16. Once all jobs on your old Jenkins server are disabled, the RelEng team will shutdown the old server (after a period of time). Or you can email helpdesk to shut down the old build server (tbachman, 18:15:11)
   17. flaviof asks whether every project has control over what maven version is used (tbachman, 18:15:33)
   18. zxiiro says we have a global for all projects, but projects can also define their own (tbachman, 18:15:48)
   19. flaviof asks why yangtools is different (tbachman, 18:17:08)
   20. rovarga says that they support 3.1.1 and 3.2, and produce both in order to not break consumers of yangtools artifacts (tbachman, 18:17:32)
   21. flaviof asks if there are multiple jobs — e.g. hydrogen, helium, lithium — can the old releases not be affected as we move forward (tbachman, 18:18:00)
   22. rovarga says yes, that’s exactly what’s being done (tbachman, 18:18:09)
   23. Goals today: discussion options for modifying process/tools (tbachman, 18:21:59)
   24. currently, all projects have the same milestones and releases, and the only way to get artifacts blessed by the TSC is to participate in the Simulataneous Release, which is monolithic (tbachman, 18:22:49)
   25. There are pros and cons to the monolithic SR (tbachman, 18:23:04)
   26. pros include “integrated”, and “official”, with a place to discuss relationship between the projects at different agreed milestones, coupled with integration testing (tbachman, 18:23:42)
   27. cons include a fair amount of overhead, which can slow projects down; There is also a perception of compatibility that is arguably illusionary (tbachman, 18:24:31)
   28. This proposal is geared towards a “distribution” model, using gated releases (tbachman, 18:25:00)
   29. Each proejct has goals set by the TSC, based on the projects life cycle (i.e. based on life cycle, they have to meet certain conditions or criteria in order to release their artifacts) (tbachman, 18:25:30)
   30. the purpose of the gated release is that artifacts can be released as soon as a project meets this criteria (tbachman, 18:25:47)
   31. this allows for more stablized artifacts to happen any time within the release time frame (tbachman, 18:26:03)
   32. At the end of a 6 month period, the stable output of all the projects will be produced, rather than build a complete snapshot (tbachman, 18:26:39)
   33. The idea is to assemble a distribution rather than provide a monolithic output (tbachman, 18:26:56)
   34. Technical Challenges include interproject dependencies, versioning practices between projects, good continuous delivery, and SNAPSHOT dependencies version management (tbachman, 18:29:21)
   35. Where “good” continuous delivery views every commit as a potential release (tbachman, 18:30:00)
   36. There’s a trade-off of building against project ranges or against whatever’s upstream (tbachman, 18:31:25)
   37. Suggested versioning practices include need to store version properties outside of build files to avoid cyclic dependencies; follow version range best practices within a release cycle; and find a way to inject current versions in the build (tbachman, 18:32:18)
   38. mlemay is working on a maven plugin that reads versions from a centralized file rather than a local file (tbachman, 18:34:00)
   39. abhijitkumbhare asks if the proposal is still propsing to use the SR but only for a group of projects (tbachman, 18:34:28)
   40. mlemay says the goal is not to abolish the SR, but have the ability to build projects more independently and have more stable artifacts at any given time given the gates (tbachman, 18:34:56)
   41. The final SR will still be decided by the TSC at the end of the SR (tbachman, 18:35:11)
   42. rovarga says that picking stable versions means that essentially our support model would change, as developers would need to know which versions of their released artifacts would make it into a released version and in need of extended support (tbachman, 18:35:48)
   43. rovarga says that this all looks good, but is not able to see what the workflow looks like as a committer (tbachman, 18:36:17)
   44. mlemay says that’s a good question, and says this is only in the brainstorming phase at the moment (tbachman, 18:36:40)
   45. edwarnicke tries to summarize by saying that there needs to be more of a continuous release, and allow projects more independence on creating their artifacts (tbachman, 18:38:12)
   46. dlenrow says yes, you’d have less moving parts to deal with than in one monolithic release (tbachman, 18:38:35)
   47. edwarnicke says that our current governance says that no project is required to join the SR (tbachman, 18:39:09)
   48. dlenrow says that the problem is that if you don’t participate in the SR, you’re on your own in creating the processes, artifacts, etc. (tbachman, 18:40:00)
   49. mlemay says one of the motivating factors behind this is that our current process won’t scale as we add more and more projects (tbachman, 18:40:59)
   50. regXboi says that this scales much worse — this adds complexity and moving parts (tbachman, 18:41:22)
   51. edwarnicke asks zxiiro how many projects went out in the last eclipse SR? (tbachman, 18:41:54)
   52. gzhao says for Helium there were 21 projects for Lithium it’s 42/43 (tbachman, 18:42:22)
   53. mohnish asks what the user consumption would look like if there are multiple projects and multiple versions (tbachman, 18:43:11)
   54. mlemay says that opens another can of worms on what is the output of ODL (tbachman, 18:43:26)
   55. https://projects.eclipse.org/releases/luna (zxiiro, 18:43:59)
   56. list of projects on simrel for Eclipse Luna (zxiiro, 18:44:15)
   57. zxiiro says eclipse SR is a bit different — all projects release artifacts to a PT repo, and a job copies all of these and merges them into one large repo (tbachman, 18:45:26)
   58. P2 repository (zxiiro, 18:46:14)
   59. It looks like the last eclipse was 75-76 sub-projects (tbachman, 18:46:51)
   60. correction on earlier info: all projects release artifacts to a P2 repo, and a job copies all of these and merges them into one large repo (tbachman, 18:47:25)
   61. zxiiro says that Eclipse does not release to Maven. They have a custom repository called P2 which every project has their own and publishes their artifacts to that which means there's 1 seperate repo URL for every project at Eclipse. Then the aggregator project mirrors all the independent release URLs and creates 1 giant repo which is called the simrel repo. (tbachman, 18:48:51)
   62. @Eclipse: So if project B depends on Project A, project A needs to first release their final artifacts first before Project B can build their final results. (zxiiro, 18:49:27)
   63. flaviof says he would love to be able to freeze things around his project and test it against that view (tbachman, 18:52:43)
   64. mlemay says that’s his point of stable artifacts during the release projects (tbachman, 18:53:17)
   65. More ideas on improving the process: incremental changes include stable versions of “core” modules; system test subsets of modules, use case specific certification; New tooling (multiple tiers of components with separable build/release, output “features” to different repos based on component maturatiy; break “offsets” into layered releases); and role of downstream/midstream projects (e.g. OPNFV is use case (tbachman, 18:56:07)
   66. dlenrow asks what testing/compatibility looks like in an eclipse release (tbachman, 19:00:12)
   67. zxiiro says that eclipse doesn’t guarantee this level of compatibility (tbachman, 19:00:37)
   68. mohnish says we can create some boundaries based on use cases for a given distribution (tbachman, 19:01:30)
   69. edwarnicke points out that we were terrible at trying to anticipate the uses cases in the hydrogen release (tbachman, 19:03:15)
   70. mlemay says there could be a middle ground where components could graduate to different feature repos (tbachman, 19:04:33)
   71. edwarnicke says that as long as we can agree on the guarantee on the criteria needed to be included in these repos, he’s fine with that (tbachman, 19:05:36)
   72. edwarnicke says that other things have been done recently to improve the consumability of ODL (e.g. removal of the -all features) (tbachman, 19:07:50)
   73. dlenrow asks what the best way is to continue this discussion (tbachman, 19:08:36)
   74. edwarnicke says the TSC is usually a good venue for this (tbachman, 19:08:46)

Action items

1. (none)

People present (lines said)

1. tbachman (108)
2. regXboi (28)
3. rovarga (13)
4. bigalh (10)
5. alagalah (9)
6. zxiiro (9)
7. odl_meetbot (8)
8. nitika (6)
9. mlemay (6)
10. abhijitkumbhare (2)
11. mohnish (1)