> That work starts at leaf projects, which have to be able to cope > with version bumps and version skew -- the first one being > integration/distribution, > which must not ensure it is pulling in exactly one version of each ODL > artifact.
Can you elaborate? I imagine by the time Carbon is released, features-index will be built using feature-repo-parent, and its pom file will specify version ranges. I am not sure whether the generated repo would refer to the same version ranges, or whether it would pick the most recent versions available during the build. Then we can create a test which would verify "exactly one version of each ODL artifact" is true, but I am not sure what to do if that test fails. Vratko. -----Original Message----- From: controller-dev-boun...@lists.opendaylight.org [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga Sent: 11 January, 2017 12:49 To: Jamo Luhrsen <jluhr...@gmail.com>; Mainzer, Gal <gmain...@hpe.com> Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; integration-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org Subject: Re: [controller-dev] [integration-dev] [mdsal-dev] 3node cluster regression in Carbon - since Jan 5th On 01/10/2017 11:12 PM, Jamo Luhrsen wrote: >> All we need to agree is that if that cloud suite is failing - all >> relevant project should stop merging (even as a process and not by a gerrit >> mechanic lock) until we are back from regression. > we aren't totally stable enough yet, imho. We are very close though. > > <devils advocate> > however convincing these dependent projects to stop merging is asking > a lot. Who says md-sal or controller gives a hoot about the "cloud" > stuff working for opendaylight. maybe other ODL projects are still > working fine and the assumption is our cloud projects are the projects that > need to fix themselves, while everyone else can continue to do work. > </devils advocate> > To expand it a bit -- the lower your offset number is, the more of these cloud-like-stuff you have in your downstream. Asking upstreams to drop everything and scramble to fix downstream issues -- whenever they surface and for whatever reason -- will mean that upstream will not get any meaningful work done. I will put it very bluntly: the root cause of the problem discussed is integration on snapshot versions. The proposal is to gate development on end-to-end tests. That leads to massive use of computing resources with the corresponding latency in development pipeline, as each patch needs to go through the full validation suite. To bring that point into perspective: would it be okay for offset-2 patches to be gated by OPNFV test suites? The proposed gating scenarios are okay for releases, not for individual patches. For that we need to move away from snapshots+autorelease to per-project release jobs. That work starts at leaf projects, which have to be able to cope with version bumps and version skew -- the first one being integration/distribution, which must not ensure it is pulling in exactly one version of each ODL artifact. Bye, Robert _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
