18:00:06 <tbachman> #startmeeting tws
18:00:06 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:06 <odl_meetbot> The meeting name has been set to 'tws'
18:00:10 <tbachman> #chair alagalah regXboi
18:00:10 <odl_meetbot> Current chairs: alagalah regXboi tbachman
18:00:12 <alagalah> zxiiro: I need the ergo keyboards now
18:00:18 <regXboi> um... don't chair me
18:00:21 <tbachman> lol
18:00:25 <regXboi> I'm not able to connect to webex
18:00:31 <alagalah> regXboi: weird
18:00:32 <tbachman> regXboi: you can be “chair-in-waiting"
18:00:38 <tbachman> (and waiting, and waiting....)
18:00:49 <regXboi> I've been unable to connect to webex for about a week and a half now
18:01:00 <tbachman> #topic agenda
18:01:08 <tbachman> regXboi: who’s your provider?
18:01:18 <regXboi> and I always get a "webex support site is currently down for maintenance"
18:01:21 <tbachman> ouch
18:01:24 <regXboi> tbachman: cox
18:01:28 <tbachman> hmmmm
18:02:01 <tbachman> 1) Simultaneous Release
18:02:06 <tbachman> 2) How to get started with JJB
18:02:11 <tbachman> #topic How to get started with JJB
18:03:18 <zxiiro> #link https://wiki.opendaylight.org/view/RelEng:Jenkins
18:03:24 <tbachman> zxiiro: thx!
18:03:26 * regXboi phone only today
18:03:35 <regXboi> #unchair regXboi
18:03:35 <odl_meetbot> Current chairs: alagalah tbachman
18:03:39 <tbachman> #undo
18:03:39 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x19bc4d0>
18:03:51 <tbachman> #link https://wiki.opendaylight.org/view/RelEng:Jenkins releng jenkins page
18:04:07 <tbachman> #info the default tab shows the daily jobs
18:04:29 <tbachman> #info most jobs use the dynamic verify slave, which is an EL6 slave JDK7 and 8 available for builds
18:04:30 <nitika> tbachman: alagalah Hi,
18:04:40 <alagalah> nitika: hi
18:04:57 <nitika> I want to discuss about the features for improving the ODL meetbot in this meeting.
18:05:03 <tbachman> #info if you just want the basic job templates, no extra action is needed once you’re set up in JJB
18:05:08 <tbachman> nitika: maybe after the meeting?
18:05:13 <alagalah> nitika: Are you with the helpdesk ?
18:05:20 <regXboi> nitika: that is going to need to wait - there is an actual meeting running
18:05:40 <tbachman> #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 <tbachman> #info all projects get a verify, merge, daily, integration, and sonar job
18:06:15 <nitika> Colin Informed to ask in this meeting only.
18:06:29 <tbachman> #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 <regXboi> whomever is typing/talking please go on mute!
18:06:38 <tbachman> nitika: he may have meant the IRC channel, not the meeting itself :)
18:06:41 <nitika> We can discuss after the meeting as well.
18:07:24 <tbachman> #info 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
18:07:35 <tbachman> #info you can push that to releng and add zxiiro and tykeal as reviewers
18:07:50 <tbachman> #info There are some customizations that can be done (see wiki)
18:07:56 <nitika> alagalah: Helpdesk ??
18:08:15 <bigalh> I believe they also want the project lead added (for the project being added to JJB)
18:08:24 <tbachman> alagalah: I think nitika is interested in doing this as a summer intern
18:08:32 <bigalh> ...if the person submitting the JJB reivew isn't said lead.
18:08:33 <tbachman> bigalh: thx!
18:08:39 <nitika> tbachman: right!
18:08:46 <tbachman> #info also add the project lead as a reviewer for the releng patch
18:11:07 <tbachman> #info If any default options are overridden, the script creates a config file for your project
18:13:11 <tbachman> #info flaviof asks what happens to the existing silo once a project transitions to JJV
18:13:14 <tbachman> #undo
18:13:14 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1932910>
18:13:27 <tbachman> #info flaviof asks what happens to the existing silo once a project transitions to JJB
18:13:51 <tbachman> #info zxiiro recommends disabling at least the existing merge job to prevent two silos merging the same artifacts
18:14:21 <bigalh> 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 <tbachman> #info edwarnicke says he disables the silos and retriggers jobs to test the JJB configuration
18:14:35 <bigalh> Or you can email helpdesk to shutdown old build server.
18:15:11 <tbachman> #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 <tbachman> bigalh: thx!
18:15:33 <tbachman> #info flaviof asks whether every project has control over what maven version is used
18:15:48 <tbachman> #info zxiiro says we have a global for all projects, but projects can also define their own
18:16:47 <bigalh> I believe some projects are enforcing a minimum required maven version in their POMs
18:17:08 <tbachman> #info flaviof asks why yangtools is different
18:17:32 <tbachman> #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 <tbachman> #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 <tbachman> #info rovarga says yes, that’s exactly what’s being done
18:20:57 <alagalah> #link https://wiki.opendaylight.org/images/e/e2/OpenDaylight_-_Release_Processxx.pptx
18:21:07 <tbachman> alagalah: thx!
18:21:12 <regXboi> alagalah: undo that and put what it is
18:21:17 <regXboi> :)
18:21:19 <tbachman> #udno
18:21:20 <tbachman> #undo
18:21:20 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1aa2750>
18:21:25 * regXboi suffers from eyebleed
18:21:42 <tbachman> : #link https://wiki.opendaylight.org/images/e/e2/OpenDaylight_-_Release_Processxx.pptx Proposal for Simultaneous Release
18:21:54 <alagalah> regXboi: ?
18:21:56 <regXboi> tbachman: thanks
18:21:59 <tbachman> #info Goals today: discussion options for modifying process/tools
18:22:01 <tbachman> regXboi: np!
18:22:09 <regXboi> alagalah: tbachman got what I wanted - what the link was with the link
18:22:24 <alagalah> 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 <tbachman> #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 <tbachman> #info There are pros and cons to the monolithic SR
18:23:42 <tbachman> #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 <tbachman> #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 <tbachman> #info This proposal is geared towards a “distribution” model, using gated releases
18:25:30 <tbachman> #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 <tbachman> #info the purpose of the gated release is that artifacts can be released as soon as a project meets this criteria
18:26:03 <tbachman> #info this allows for more stablized artifacts to happen any time within the release time frame
18:26:39 <tbachman> #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 <regXboi> which slide are we on, 4 or 5?
18:26:56 <tbachman> #info The idea is to assemble a distribution rather than provide a monolithic output
18:27:05 <tbachman> regXboi: not sure (don’t see slide #'s)
18:27:11 <tbachman> Shows “Gate 1, Gate 2)
18:27:24 <tbachman> title “Towards a distribution model?”
18:27:37 <regXboi> ah - that's 4 - thanks
18:27:39 <tbachman> 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 <regXboi> alagalah: make a note :)
18:28:31 <alagalah> regXboi: Duly noted
18:29:21 <tbachman> #info Technical Challenges include interproject dependencies,  versioning practices between projects, good continuous delivery, and SNAPSHOT dependencies version management
18:30:00 <tbachman> #info Where “good” continuous delivery views every commit as a potential release
18:31:25 <tbachman> #info There’s a trade-off of building against project ranges or against whatever’s upstream
18:32:18 <tbachman> #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 <tbachman> #info mlemay is working on a maven plugin that reads versions from a centralized file rather than a local file
18:34:28 <tbachman> #info abhijitkumbhare asks if the proposal is still propsing to use the SR but only for a group of projects
18:34:56 <tbachman> #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 <tbachman> #info The final SR will still be decided by the TSC at the end of the SR
18:35:48 <tbachman> #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 <regXboi> beautiful?  sorry, this looks like a mess to me...
18:36:17 <tbachman> #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 <tbachman> #info mlemay says that’s a good question, and says this is only in the brainstorming phase at the moment
18:38:12 <tbachman> #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 <tbachman> #info dlenrow says yes, you’d have less moving parts to deal with than in one monolithic release
18:38:47 <rovarga> mlemay: dlenrow: one thing is ... how to coerce projects to upgrade to the next major release of a infrastructure component
18:39:09 <tbachman> #info edwarnicke says that our current governance says that no project is required to join the SR
18:39:47 <mlemay> rovarga: indeed that is a point I've been thinking about
18:40:00 <tbachman> #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 <rovarga> 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 <tbachman> #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 <tbachman> #info regXboi says that this scales much worse — this adds complexity and moving parts
18:41:54 <tbachman> #info edwarnicke asks zxiiro how many projects went out in the last eclipse SR?
18:42:04 <rovarga> regXboi: aside from managing version skew, the proposal is actually less fragile
18:42:22 <tbachman> #info gzhao says for Helium there were 21 projects for Lithium it’s 42/43
18:42:25 <regXboi> rovarga: honestly, I'm not seeing it
18:42:47 <alagalah> edwarnicke: You appear to have lost your audio
18:43:07 <regXboi> rovarga: I've been trying to see how to get from here to there and I'm still not seeing it
18:43:11 <tbachman> #info mohnish asks what the user consumption would look like if there are multiple projects and multiple versions
18:43:26 <tbachman> #info mlemay says that opens another can of worms on what is the output of ODL
18:43:37 <rovarga> regXboi: so now we're on snapshots and we have no inter-project gating
18:43:49 <abhijitkumbhare> 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 <zxiiro> #link https://projects.eclipse.org/releases/luna
18:44:15 <zxiiro> #info list of projects on simrel for Eclipse Luna
18:44:19 <rovarga> regXboi: quite frankly, we need yangtools and the like released before the next 'SR' of things using them
18:45:26 <tbachman> #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 <rovarga> 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 <zxiiro> #info P2 repository
18:46:45 <regXboi> 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 <tbachman> #info It looks like the last eclipse was 75-76 sub-projects
18:46:56 <tbachman> zxiiro: thx!
18:46:59 <tbachman> sorry for the error
18:47:25 <tbachman> #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 <rovarga> regXboi: that was my question on mlemay :-)
18:48:01 <regXboi> rovarga: and that's the part that makes me go this isn't simpler :)
18:48:25 <zxiiro> 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 <rovarga> 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 <tbachman> zxiiro: thx!
18:48:51 <tbachman> #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 <mlemay> rovarga: that is my suggestion
18:49:15 <rovarga> regXboi: historically, the infra project members have migrated the users... which is *not* what we can do
18:49:27 <zxiiro> #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 <mlemay> rovarga: the TSC should mandate the "platform" versions for components and this way it can "range" constraints teh component
18:49:42 <regXboi> rovarga: um, that's said to internal project?
18:49:50 <regXboi> mlemay: uh really????
18:49:52 <mlemay> without having to "rebuild" the world all the time
18:50:10 <rovarga> mlemay: well, you still need to validate the distro :)
18:50:23 <mlemay> rovarga: of course
18:51:18 <abhijitkumbhare> +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 <rovarga> 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 <bigalh> :)
18:52:20 <mohnish> +1 for Flavio
18:52:41 <mlemay> +1 to Flavio
18:52:43 <tbachman> #info flaviof says he would love to be able to freeze things around his project and test it against that view
18:53:12 <zxiiro> Sounds like what a Tag is for
18:53:17 <tbachman> #info mlemay says that’s his point of stable artifacts during the release projects
18:53:20 <regXboi> zxiiro: +1
18:53:34 <tbachman> and we need a place for those artifacts based on tags tho, right?
18:53:57 <bigalh> that's the tough part
18:54:03 <bigalh> how do you do a "tag" in Nexus?
18:54:18 <bigalh> ..other than version/snapshot #s
18:54:24 <rovarga> bigalh: that's what version is for :)
18:55:10 * bigalh grins.
18:56:07 <tbachman> #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 <tbachman> specific test/cert/deploy project)
18:56:58 <zxiiro> 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 <tbachman> #info dlenrow asks what testing/compatibility looks like in an eclipse release
19:00:37 <tbachman> #info zxiiro says that eclipse doesn’t guarantee this level of compatibility
19:01:30 <tbachman> #info mohnish says we can create some boundaries based on use cases for a given distribution
19:03:15 <tbachman> #info edwarnicke points out that we were terrible at trying to anticipate the uses cases in the hydrogen release
19:03:35 <zxiiro> 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 <tbachman> #info mlemay says there could be a middle ground where components could graduate to different feature repos
19:05:36 <tbachman> #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 <tbachman> #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 <tbachman> #info dlenrow asks what the best way is to continue this discussion
19:08:46 <tbachman> #info edwarnicke says the TSC is usually a good venue for this
19:09:28 <tbachman> #endmeeting