18:00:06 #startmeeting tws 18:00:06 Meeting started Mon Feb 2 18:00:06 2015 UTC. The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html. 18:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:06 The meeting name has been set to 'tws' 18:00:10 #chair alagalah regXboi 18:00:10 Current chairs: alagalah regXboi tbachman 18:00:12 zxiiro: I need the ergo keyboards now 18:00:18 um... don't chair me 18:00:21 lol 18:00:25 I'm not able to connect to webex 18:00:31 regXboi: weird 18:00:32 regXboi: you can be “chair-in-waiting" 18:00:38 (and waiting, and waiting....) 18:00:49 I've been unable to connect to webex for about a week and a half now 18:01:00 #topic agenda 18:01:08 regXboi: who’s your provider? 18:01:18 and I always get a "webex support site is currently down for maintenance" 18:01:21 ouch 18:01:24 tbachman: cox 18:01:28 hmmmm 18:02:01 1) Simultaneous Release 18:02:06 2) How to get started with JJB 18:02:11 #topic How to get started with JJB 18:03:18 #link https://wiki.opendaylight.org/view/RelEng:Jenkins 18:03:24 zxiiro: thx! 18:03:26 * regXboi phone only today 18:03:35 #unchair regXboi 18:03:35 Current chairs: alagalah tbachman 18:03:39 #undo 18:03:39 Removing item from minutes: 18:03:51 #link https://wiki.opendaylight.org/view/RelEng:Jenkins releng jenkins page 18:04:07 #info the default tab shows the daily jobs 18:04:29 #info most jobs use the dynamic verify slave, which is an EL6 slave JDK7 and 8 available for builds 18:04:30 tbachman: alagalah Hi, 18:04:40 nitika: hi 18:04:57 I want to discuss about the features for improving the ODL meetbot in this meeting. 18:05:03 #info if you just want the basic job templates, no extra action is needed once you’re set up in JJB 18:05:08 nitika: maybe after the meeting? 18:05:13 nitika: Are you with the helpdesk ? 18:05:20 nitika: that is going to need to wait - there is an actual meeting running 18:05:40 #info 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) 18:06:03 #info all projects get a verify, merge, daily, integration, and sonar job 18:06:15 Colin Informed to ask in this meeting only. 18:06:29 #info in gerrit, you can use the keywords recheck or remerge, and it will cause the jobs to be retriggered by the patch 18:06:38 whomever is typing/talking please go on mute! 18:06:38 nitika: he may have meant the IRC channel, not the meeting itself :) 18:06:41 We can discuss after the meeting as well. 18:07:24 #info you can run python scripts/jjb-init-project.py to generate the demo file that defines all the jobs for your project 18:07:35 #info you can push that to releng and add zxiiro and tykeal as reviewers 18:07:50 #info There are some customizations that can be done (see wiki) 18:07:56 alagalah: Helpdesk ?? 18:08:15 I believe they also want the project lead added (for the project being added to JJB) 18:08:24 alagalah: I think nitika is interested in doing this as a summer intern 18:08:32 ...if the person submitting the JJB reivew isn't said lead. 18:08:33 bigalh: thx! 18:08:39 tbachman: right! 18:08:46 #info also add the project lead as a reviewer for the releng patch 18:11:07 #info If any default options are overridden, the script creates a config file for your project 18:13:11 #info flaviof asks what happens to the existing silo once a project transitions to JJV 18:13:14 #undo 18:13:14 Removing item from minutes: 18:13:27 #info flaviof asks what happens to the existing silo once a project transitions to JJB 18:13:51 #info zxiiro recommends disabling at least the existing merge job to prevent two silos merging the same artifacts 18:14:21 Once all jobs on your old Jenkins server are disabled, the RelEng team will shutdown the old server (after a period of time). 18:14:25 #info edwarnicke says he disables the silos and retriggers jobs to test the JJB configuration 18:14:35 Or you can email helpdesk to shutdown old build server. 18:15:11 #info 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 18:15:15 bigalh: thx! 18:15:33 #info flaviof asks whether every project has control over what maven version is used 18:15:48 #info zxiiro says we have a global for all projects, but projects can also define their own 18:16:47 I believe some projects are enforcing a minimum required maven version in their POMs 18:17:08 #info flaviof asks why yangtools is different 18:17:32 #info rovarga says that they support 3.1.1 and 3.2, and produce both in order to not break consumers of yangtools artifacts 18:18:00 #info flaviof asks if there are multiple jobs — e.g. hydrogen, helium, lithium — can the old releases not be affected as we move forward 18:18:09 #info rovarga says yes, that’s exactly what’s being done 18:20:57 #link https://wiki.opendaylight.org/images/e/e2/OpenDaylight_-_Release_Processxx.pptx 18:21:07 alagalah: thx! 18:21:12 alagalah: undo that and put what it is 18:21:17 :) 18:21:19 #udno 18:21:20 #undo 18:21:20 Removing item from minutes: 18:21:25 * regXboi suffers from eyebleed 18:21:42 : #link https://wiki.opendaylight.org/images/e/e2/OpenDaylight_-_Release_Processxx.pptx Proposal for Simultaneous Release 18:21:54 regXboi: ? 18:21:56 tbachman: thanks 18:21:59 #info Goals today: discussion options for modifying process/tools 18:22:01 regXboi: np! 18:22:09 alagalah: tbachman got what I wanted - what the link was with the link 18:22:24 regXboi: Ah, yes, sorry 18:22:29 * regXboi thinking of the minute readers later on - naked link only slightly better than naked ping 18:22:49 #info 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 18:23:04 #info There are pros and cons to the monolithic SR 18:23:42 #info pros include “integrated”, and “official”, with a place to discuss relationship between the projects at different agreed milestones, coupled with integration testing 18:24:31 #info cons include a fair amount of overhead, which can slow projects down; There is also a perception of compatibility that is arguably illusionary 18:25:00 #info This proposal is geared towards a “distribution” model, using gated releases 18:25:30 #info 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) 18:25:47 #info the purpose of the gated release is that artifacts can be released as soon as a project meets this criteria 18:26:03 #info this allows for more stablized artifacts to happen any time within the release time frame 18:26:39 #info At the end of a 6 month period, the stable output of all the projects will be produced, rather than build a complete snapshot 18:26:49 which slide are we on, 4 or 5? 18:26:56 #info The idea is to assemble a distribution rather than provide a monolithic output 18:27:05 regXboi: not sure (don’t see slide #'s) 18:27:11 Shows “Gate 1, Gate 2) 18:27:24 title “Towards a distribution model?” 18:27:37 ah - that's 4 - thanks 18:27:39 np! 18:27:52 * regXboi notes: people need to have numbers on the slides 18:28:03 * regXboi notes: so that folks not on webex can follow along 18:28:14 alagalah: make a note :) 18:28:31 regXboi: Duly noted 18:29:21 #info Technical Challenges include interproject dependencies, versioning practices between projects, good continuous delivery, and SNAPSHOT dependencies version management 18:30:00 #info Where “good” continuous delivery views every commit as a potential release 18:31:25 #info There’s a trade-off of building against project ranges or against whatever’s upstream 18:32:18 #info 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 18:34:00 #info mlemay is working on a maven plugin that reads versions from a centralized file rather than a local file 18:34:28 #info abhijitkumbhare asks if the proposal is still propsing to use the SR but only for a group of projects 18:34:56 #info 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 18:35:11 #info The final SR will still be decided by the TSC at the end of the SR 18:35:48 #info 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 18:36:10 beautiful? sorry, this looks like a mess to me... 18:36:17 #info rovarga says that this all looks good, but is not able to see what the workflow looks like as a committer 18:36:40 #info mlemay says that’s a good question, and says this is only in the brainstorming phase at the moment 18:38:12 #info 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 18:38:35 #info dlenrow says yes, you’d have less moving parts to deal with than in one monolithic release 18:38:47 mlemay: dlenrow: one thing is ... how to coerce projects to upgrade to the next major release of a infrastructure component 18:39:09 #info edwarnicke says that our current governance says that no project is required to join the SR 18:39:47 rovarga: indeed that is a point I've been thinking about 18:40:00 #info 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. 18:40:39 mlemay: so far the infra components have pretty much done the work, but that is probably not going to cut it with the sheer number of projects 18:40:59 #info mlemay says one of the motivating factors behind this is that our current process won’t scale as we add more and more projects 18:41:22 #info regXboi says that this scales much worse — this adds complexity and moving parts 18:41:54 #info edwarnicke asks zxiiro how many projects went out in the last eclipse SR? 18:42:04 regXboi: aside from managing version skew, the proposal is actually less fragile 18:42:22 #info gzhao says for Helium there were 21 projects for Lithium it’s 42/43 18:42:25 rovarga: honestly, I'm not seeing it 18:42:47 edwarnicke: You appear to have lost your audio 18:43:07 rovarga: I've been trying to see how to get from here to there and I'm still not seeing it 18:43:11 #info mohnish asks what the user consumption would look like if there are multiple projects and multiple versions 18:43:26 #info mlemay says that opens another can of worms on what is the output of ODL 18:43:37 regXboi: so now we're on snapshots and we have no inter-project gating 18:43:49 Will there be a risk of set of projects getting clubbed into a distro which takes up a lot of cycles for 1-2 core projects within the distro - which starves the other projects dependent on these 1-2 core projects? 18:43:59 #link https://projects.eclipse.org/releases/luna 18:44:15 #info list of projects on simrel for Eclipse Luna 18:44:19 regXboi: quite frankly, we need yangtools and the like released before the next 'SR' of things using them 18:45:26 #info 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 18:45:35 regXboi: as to the way of getting from here to there, we need to decouple 'project' version from the 'artifact' versions -- which is what we are trying to achieve in this release cycle 18:46:14 #info P2 repository 18:46:45 rovarga: assuming we decouple artifact version, what's then to prevent needing to carry around multiple versions of the same artifact because projects work with different versions? 18:46:51 #info It looks like the last eclipse was 75-76 sub-projects 18:46:56 zxiiro: thx! 18:46:59 sorry for the error 18:47:25 #info 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 18:47:39 regXboi: that was my question on mlemay :-) 18:48:01 rovarga: and that's the part that makes me go this isn't simpler :) 18:48:25 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. 18:48:32 regXboi: but one way of achieving it is the 'platform release mandate', where you say "this next release will have version 2 of this component, which has been tested and is supported. if you are on version 1, you are on your own" :-D 18:48:42 zxiiro: thx! 18:48:51 #info 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. 18:48:53 rovarga: that is my suggestion 18:49:15 regXboi: historically, the infra project members have migrated the users... which is *not* what we can do 18:49:27 #info @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. 18:49:36 rovarga: the TSC should mandate the "platform" versions for components and this way it can "range" constraints teh component 18:49:42 rovarga: um, that's said to internal project? 18:49:50 mlemay: uh really???? 18:49:52 without having to "rebuild" the world all the time 18:50:10 mlemay: well, you still need to validate the distro :) 18:50:23 rovarga: of course 18:51:18 +1 to Uri's point - this conversation (ODL as bag of parts or platform) should happen at all levels (not just board) 18:51:37 regXboi: look, as an infra component I cannot maintain stuff forever. and if a project refuses to migrate, well... that's the nice thing about the dictature of majority^W^W^W^Wdemocracy... 18:51:53 * tbachman notes that it’s hard to capture all these conversations 18:52:10 :) 18:52:20 +1 for Flavio 18:52:41 +1 to Flavio 18:52:43 #info flaviof says he would love to be able to freeze things around his project and test it against that view 18:53:12 Sounds like what a Tag is for 18:53:17 #info mlemay says that’s his point of stable artifacts during the release projects 18:53:20 zxiiro: +1 18:53:34 and we need a place for those artifacts based on tags tho, right? 18:53:57 that's the tough part 18:54:03 how do you do a "tag" in Nexus? 18:54:18 ..other than version/snapshot #s 18:54:24 bigalh: that's what version is for :) 18:55:10 * bigalh grins. 18:56:07 #info 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 18:56:08 specific test/cert/deploy project) 18:56:58 hard to do but if a tag = a release then we'd publish final build result by building the tag rather than by building against master and release the built tag. The downside to that is if we find a late issue then to fix it we'd need yet another tag :/ 19:00:12 #info dlenrow asks what testing/compatibility looks like in an eclipse release 19:00:37 #info zxiiro says that eclipse doesn’t guarantee this level of compatibility 19:01:30 #info mohnish says we can create some boundaries based on use cases for a given distribution 19:03:15 #info edwarnicke points out that we were terrible at trying to anticipate the uses cases in the hydrogen release 19:03:35 Projects do the best they can to test against features they expect users to use together but don't go out of their way to ensure every feature works with every other feature. 19:04:33 #info mlemay says there could be a middle ground where components could graduate to different feature repos 19:05:36 #info 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 19:06:38 * tbachman notes we are 6 minutes past 19:07:34 * rovarga drops off at a critical time :-/ 19:07:50 #info edwarnicke says that other things have been done recently to improve the consumability of ODL (e.g. removal of the -all features) 19:08:36 #info dlenrow asks what the best way is to continue this discussion 19:08:46 #info edwarnicke says the TSC is usually a good venue for this 19:09:28 #endmeeting