Gary, Oliver, I have discussed again this topic with Christophe this morning
Looking at the number of potential project proposals, we believe that the versioning could be handled independently The key is to publish the Manifesto for each release containing the good combination of containers, artifacts etc. This is also a lesson learnt from the OpenStack Community. I believe we should move in that direction except if the ONAP TSC does not agree Best regards Catherine -----Original Message----- From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Wednesday, May 31, 2017 7:05 PM To: SPATSCHECK, OLIVER <spat...@research.att.com> Cc: onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Hi Oliver, There are definitely disadvantages to keeping all versions in sync, as you mentioned. I think the main issue to decide on is this: To what degree will the ONAP community support a mix of different versions of different modules? If each module is independently versioned, then which specific version combinations will ONAP officially support for each ONAP release? * If we only support one canonical combination, then we might as well keep all versions in sync. * If we support arbitrary version combinations, then the number of possible combinations becomes astronomical. * Or maybe it's somewhere between the two, i.e. keep a small list of specific, supported version combinations, maybe corresponding to a few critical fixes only. Any bug fix or version bump in any module has the potential to introduce a breaking change against some specific versions of another module, or even breaking compatibility with a VNF that had been certified against a particular "base release" of ONAP. How should we address such issues? How should we respond to people who are using a version combination that is not officially supported? I can see pros and cons to either approach (sync all versions or not), which is why the TSC probably needs to weigh in on this. Thanks, Gary -----Original Message----- From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] Sent: Wednesday, May 31, 2017 6:22 AM To: Gary Wu <gary.i...@huawei.com> Cc: CLOSSET, CHRISTOPHE <cc6...@intl.att.com>; Andrew Grimberg <agrimb...@linuxfoundation.org>; Coquelin, Sebastien <sebastien.coque...@bell.ca>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Gary, thanks for the summary. I would NOT try to keep the version numbers in sync. Either way creates work and I believe keeping them in sync creates much more work. E.g. if you apply a patch to a jar file (let’s say an emergency security patch which will come..) in a release branch does that mean everybody has to generate a jar file with the matching version number and push it out even if nothing changed? So that creates work for 31 projects (current count) when one project fixes a bug in one jar file. Does even the documentation projects have to bump the version number on there documentation because somebody edited a jar file? That either slows down patching or generates a lot of work for a lot of people. Even keeping mayor version numbers in sync is questionable to me. E.g. if two years from now a new project is started and ONAP is on release 4.x.x does that mean a fairly new jar file should start out with release number 4.x.x ? That would indicate much more maturity then the jar file probably has at that point in time and is misleading to the user. So I would have an ONAP release number and version numbers of artifacts which tie into a release. I am not quite sure why that would be more work then above. Oliver > On May 30, 2017, at 6:49 PM EDT, Gary Wu <gary.i...@huawei.com> wrote: > > A quick summary of our call this morning with myself, Christophe, and > Sebastien: > > The consensus is that we’re ok to move the Java artifacts back to SNAPSHOT > versioning (and thereby removing build dependencies on Staging repos) as long > as the docker images can continue with the current STAGING tags. Christophe > will check back with AT&T teams to organize this effort, hopefully to be done > within a few days. > > One big open issue for the TSC to decide is whether we want to keep all Java > artifact versions in sync across all modules/projects (i.e. version 1.0.0) > for each ONAP release, or if we want to support a mix of independent version > numbers and release cycles per project or even per jar file. For reference, > Open-O decided on the former in order to minimize support and maintenance > costs. > > Thanks, > Gary > > > From: Closset, Christophe [mailto:cc6...@intl.att.com] > Sent: Monday, May 29, 2017 6:22 AM > To: SPATSCHECK, OLIVER <spat...@research.att.com>; Andrew Grimberg > <agrimb...@linuxfoundation.org> > Cc: Gary Wu <gary.i...@huawei.com>; Coquelin, Sebastien > <sebastien.coque...@bell.ca>; onap-discuss@lists.onap.org > Subject: RE: [onap-discuss] Staging repo in settings.xml > > I’ll set up a call to discuss this further. > > I think we need to have a TSC decision on : > - Do we want to freeze artifacts from seed code release 1.0.0 (the > stable one) and/or 1.1.0 (the enhanced and catch up code) or not ? > o A mitigated action could be to just go and bless the Docker containers > from the stable build that we have – which is what people are trialing > against and rename the stable branch to something more meaningful (just keep > it for historical purpose and as an easy way for people to see the code they > are running their trial on), then for the current master we can probably move > away from staging and go to snapshots as suggested below. > - Do we formally remove artifact version numbering from ONAP release > numbering ? > o If we do, then we could question the whole staging approach. > > Few things to note when moving away from staging: > - I don’t think there is a formal list of which artifacts are coming > from staging, now disabling the staging repo will quickly highlight them. > This will need attention from all teams to fix their builds with proper > snapshots. > We’ve noticed that the build nodes do not start from an empty .m2 repository > so it might obfuscate issues. > - We will need to setup daily snapshot builds (right now we have > daily release against staging build) to keep up building our daily docker > images, sonar scans etc… - we will need to adapt the docker images tag to > reflect that situation > - We will need each team to adapt their jjb jobs and templates to > have a way to re-enable staging easily > > Just to say that it’s not straightforward and will most probably take > a few days before we get all components buildable again on master > > Regards > Christophe > > From: SPATSCHECK, OLIVER > Sent: Friday, May 26, 2017 2:19 PM > To: Andrew Grimberg <agrimb...@linuxfoundation.org> > Cc: Gary Wu <gary.i...@huawei.com>; Coquelin, Sebastien > <sebastien.coque...@bell.ca>; Closset, Christophe > <cc6...@intl.att.com>; onap-discuss@lists.onap.org > Subject: Re: [onap-discuss] Staging repo in settings.xml > > > Would have to talk to all the teams to get the details but I think most > artifacts need to be locked down. Please remember that since we created the > 1.0.0 branch we have been contributing code based on two additional internal > releases into the seed repos. This new code base has not been fully tested > yet (we took some shortcuts)to catch up. So if we remove the 1.0.0 branch we > don’t have a working system right now. > > I also think that artifact versioning shouldn’t match the ONAP release > versioning. I think trying to keep that all in sync with the number of > artifacts we have is a nightmare. E.g. will you be rolling the artifact > version number on the Open-O artifacts back to 1.0.0? I would just leave them > where they are. Otherwise you will have people with incorrect artifacts in > there maven caches. This seems to be just generating additional > work/confusion with little practical value. > > Oliver > > On May 25, 2017, at 5:55 PM, Andrew Grimberg <agrimb...@linuxfoundation.org> > wrote: > > On 05/25/2017 02:36 PM, Gary Wu wrote: > > That makes sense given that staging artifacts were supposed to exist > only long enough to decide whether they're good to release or not; > they were not meant to be used as long-lived build dependencies. > > I think the right thing to do is to move away from this "build against > staging" approach relatively soon. Given that our formal 1st release > is November, and assuming that the release artifact version will be > "1.0.0", I see two options: > > 1. Do not release any thing from staging right now. Change all > artifact versions to 1.0.0-SNAPSHOT. > > 2. For the subset of artifacts that need to be "locked down", > actually release the staging candidates right now as 1.0.0-RC0 or some > such. Then change all artifact versions to 1.0.0-SNAPSHOT, except > explicit dependencies on the released 1.0.0-RC0 artifacts where > desired. > > Any other ideas? > > Do we have a full list of the artifacts that explicitly need to be > served up from staging repos right now? I'm hoping this list is > relatively short. > > Not something I can answer. I would hope that the seed projects can > answer that. > > -Andy- > > -- > Andrew J Grimberg > Lead, IT Release Engineering > The Linux Foundation _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=66ObImPAUA0o2f1hTGknnnv5ScXvX8EnREJCPHHBY5M&m=7xClrH-N0DOQsMfaoHrE30hvh4AkuhI6Z5cCJHKgsAk&s=lZRkcgmJpa_lIVnmK1rfrN3gxR-spT5V_c1bDBwSsl4&e= _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
