Re: [onap-discuss] Staging repo in settings.xml
Ok, that sounds like a good approach, namely: * Projects / modules independently versioned, and * Small number of officially supported version manifests. Andy, can you chime in on how this would work from the release perspective? In OPEN-O we had one central release (multiple deploys to staging, then pick one to move to release repo) and you personally signed the artifacts. How would this flow work when each project will release on their own timeline? Can/would we automate this so that each project PTL will have full control to determine which staging artifact to release, and to sign the artifacts? We would also need to amend and clarify in the Release Plan what this means for the "Simultaneous Release", e.g. when is the cutoff for each project team to submit its final version to be included in the official manifest. Maybe there is a manifest file in the Integration project that lists the specific modules versions that should be pulled for running the CSIT/ETE tests, etc. Thanks, Gary -Original Message- From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] Sent: Thursday, June 01, 2017 6:21 AM To: Gary Wu Cc: CLOSSET, CHRISTOPHE ; Andrew Grimberg ; Coquelin, Sebastien ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml In terms of support I think we will support a small number of version combinations. In a sense cutting a release just becomes the act of blessing a Manifesto and we need to make sure we only bless a manageable number of Manifestos. This approach also allows others to cut “unofficial” (none community supported) releases if they choose to do so using the same mechanism used for official releases (cutting down extra work required otherwise) with the only difference being that the Manifesto is not supported. As for bug fixes impacting other modules that has to be managed as in any other complex system. In theory anything can impact anything in a large system. Modularization and strong API discipline mitigates some of that. So based on the complexity of the bug fix somebody has to make a value judgement what testing will be necessary before we are willing to bless the new Manifesto, but again this approach allows the user to make his/her own risk assessment. E.g. if a bug fix is committed but not blessed yet AT&T might choose to already use the fixed version just by using an unsupported Manifesto or we might not. We will make that call based on the risk/reward tradeoff at the time and don’t have to wait for others to make that decision for us. Oliver > On May 31, 2017, at 1:05 PM, Gary Wu wrote: > > 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 > Cc: CLOSSET, CHRISTOPHE ; Andrew Grimberg > ; Coquelin, Sebastien > ; 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 wor
Re: [onap-discuss] Staging repo in settings.xml
In terms of support I think we will support a small number of version combinations. In a sense cutting a release just becomes the act of blessing a Manifesto and we need to make sure we only bless a manageable number of Manifestos. This approach also allows others to cut “unofficial” (none community supported) releases if they choose to do so using the same mechanism used for official releases (cutting down extra work required otherwise) with the only difference being that the Manifesto is not supported. As for bug fixes impacting other modules that has to be managed as in any other complex system. In theory anything can impact anything in a large system. Modularization and strong API discipline mitigates some of that. So based on the complexity of the bug fix somebody has to make a value judgement what testing will be necessary before we are willing to bless the new Manifesto, but again this approach allows the user to make his/her own risk assessment. E.g. if a bug fix is committed but not blessed yet AT&T might choose to already use the fixed version just by using an unsupported Manifesto or we might not. We will make that call based on the risk/reward tradeoff at the time and don’t have to wait for others to make that decision for us. Oliver > On May 31, 2017, at 1:05 PM, Gary Wu wrote: > > 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 > Cc: CLOSSET, CHRISTOPHE ; Andrew Grimberg > ; Coquelin, Sebastien > ; 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 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 t
Re: [onap-discuss] Staging repo in settings.xml
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 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 Cc: CLOSSET, CHRISTOPHE ; Andrew Grimberg ; Coquelin, Sebastien ; 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 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 ; Andrew Grimberg > > Cc: Gary Wu ; Coquelin, Sebastien > ; onap-discuss@lists.onap.org > Subject: RE: [onap-discuss] Staging repo in settings.xml > > I’l
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 Cc: CLOSSET, CHRISTOPHE ; Andrew Grimberg ; Coquelin, Sebastien ; 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 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 ; Andrew Grimberg > > Cc: Gary Wu ; Coquelin, Sebastien > ; 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 ? &
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 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 ; Andrew Grimberg > > Cc: Gary Wu ; Coquelin, Sebastien > ; 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 > Cc: Gary Wu ; Coquelin, Sebastien > ; Closset, Christophe ; > 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
Re: [onap-discuss] Staging repo in settings.xml
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 ; Andrew Grimberg Cc: Gary Wu ; Coquelin, Sebastien ; 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 mailto:agrimb...@linuxfoundation.org>> Cc: Gary Wu mailto:gary.i...@huawei.com>>; Coquelin, Sebastien mailto:sebastien.coque...@bell.ca>>; Closset, Christophe mailto:cc6...@intl.att.com>>; onap-discuss@lists.onap.org<mailto: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 mailto: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
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 Cc: Gary Wu ; Coquelin, Sebastien ; Closset, Christophe ; 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 mailto: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://lists.onap.org/mailman/listinfo/onap-discuss
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 mailto: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://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] Staging repo in settings.xml
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 signature.asc Description: OpenPGP digital signature ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] Staging repo in settings.xml
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. Thanks, Gary -Original Message- From: Andrew Grimberg [mailto:agrimb...@linuxfoundation.org] Sent: Thursday, May 25, 2017 7:24 AM To: SPATSCHECK, OLIVER (OLIVER) ; Gary Wu Cc: Coquelin, Sebastien ; CLOSSET, CHRISTOPHE ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml On 05/24/2017 11:34 AM, SPATSCHECK, OLIVER (OLIVER) wrote: > >> On May 24, 2017, at 10:54 AM EDT, Gary Wu >> wrote: >> >> 3) I understand that all the staging process was meant to be >> temporary, and to add on Gary’s last question, what is the plan >> moving forward and how could we contribute to that effort ? > > I think that’s a TSC question. We wouldn’t mind moving this to a > formal release just because it makes it easier to deal with the code. > However, the current plan is to have the first formal release in > November when the code bases have merged and not on the seed code in > the current repos. Assuming we stick with that plan it means we will > stay in staging at least till November to ensure we have a working > code base for demos etc… . One things I'll note about the setup. Our staging repositories are dropped after 14 days. This is a hard drop, so if artifacts that are there need to stick around at all right now they need to be regularly refreshed _or_ a release needs to actually happen. -Andy- -- Andrew J Grimberg Lead, IT Release Engineering The Linux Foundation ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] Staging repo in settings.xml
On 05/24/2017 11:34 AM, SPATSCHECK, OLIVER (OLIVER) wrote: > >> On May 24, 2017, at 10:54 AM EDT, Gary Wu >> wrote: >> >> 3) I understand that all the staging process was meant to be >> temporary, and to add on Gary’s last question, what is the plan >> moving forward and how could we contribute to that effort ? > > I think that’s a TSC question. We wouldn’t mind moving this to a > formal release just because it makes it easier to deal with the code. > However, the current plan is to have the first formal release in > November when the code bases have merged and not on the seed code in > the current repos. Assuming we stick with that plan it means we will > stay in staging at least till November to ensure we have a working > code base for demos etc… . One things I'll note about the setup. Our staging repositories are dropped after 14 days. This is a hard drop, so if artifacts that are there need to stick around at all right now they need to be regularly refreshed _or_ a release needs to actually happen. -Andy- -- Andrew J Grimberg Lead, IT Release Engineering The Linux Foundation signature.asc Description: OpenPGP digital signature ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] Staging repo in settings.xml
> On May 24, 2017, at 10:54 AM EDT, Gary Wu wrote: > > 3) I understand that all the staging process was meant to be temporary, and > to add on Gary’s last question, what is the plan moving forward and how could > we contribute to that effort ? I think that’s a TSC question. We wouldn’t mind moving this to a formal release just because it makes it easier to deal with the code. However, the current plan is to have the first formal release in November when the code bases have merged and not on the seed code in the current repos. Assuming we stick with that plan it means we will stay in staging at least till November to ensure we have a working code base for demos etc… . Oliver ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] Staging repo in settings.xml
#1 is correct; the Pro version is required to use the Staging repos feature. #2: if you don't have Pro version, you won't be able to deploy to a staging repo. You should still be able to build the SNAPSHOT artifacts that pull staging dependencies, but those will need to come from the LF Nexus. #3: Hopefully Christophe or someone else can chime in. Thanks, Gary -Original Message- From: Coquelin, Sebastien [mailto:sebastien.coque...@bell.ca] Sent: Wednesday, May 24, 2017 7:50 AM To: Gary Wu ; Closset, Christophe ; Andrew Grimberg ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Hi Christophe, Gary, Andy, I’m trying also to build projects on a local Jenkins and I’m facing some issues related to the nexus-staging-maven-plugin. I am reaching out to clarify a few things : 1) On the nexus-staging-maven-plugin documentation page (https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin), it states that it’s mandatory to have the Nexus Repository Pro version to leverage the staging feature. Can you please confirm ? 2) Is there any – quick - workaround to build all projects and skip the staging step if we want to stick with Nexus Repository OSS version ? 3) I understand that all the staging process was meant to be temporary, and to add on Gary’s last question, what is the plan moving forward and how could we contribute to that effort ? Thanks, Sébastien On 2017-05-16, 1:30 PM, "onap-discuss-boun...@lists.onap.org on behalf of Gary Wu" wrote: Hi Christophe, Thanks for adding the historical context. If I understand correctly, the staging approach was meant to be temporary right before a release. Is a release imminent, or has that been canceled? What's the current timeline to move all the artifacts back to SNAPSHOT versioning (and remove Staging repo from build dependencies) in preparation for active ONAP development? Thanks, Gary -Original Message- From: Closset, Christophe [mailto:cc6...@intl.att.com] Sent: Friday, May 12, 2017 5:52 AM To: Gary Wu ; Andrew Grimberg ; onap-discuss@lists.onap.org Subject: RE: [onap-discuss] Staging repo in settings.xml Hi Gary, Andy, As for the OpenECOMP history, the whole original idea was also to align everyone's release number and date to a common one for the launch (the current release-1.0.0 branch). Concerns were raised in the dev teams (as you pointed below) that everyone's pace would be different eventually and that we should have a way of releasing components independently even though we have serious inter dependencies within ONAP. So instead of a MEGA build - all components have their independent release jobs building on staging. This hybrid approach somehow suited us nicely, now we did not go through the blessing process to move all these to proper release artifacts and kept moving with this in the master branch as Andy explained. I agree that it's confusing and not ideal right now (the concept of not really released 'release artifacts' is puzzling at first but we got used to it). If (and that's probably a TSC decision to make) we want to move to a fully decoupled model - which with the number of repositories growing is probably a good idea - then we should also remove the joint numbering somewhat (TSC) so that components can truly release independently. This indeed brings the issue of managing dependencies in a non-intuitive manner (I'm building ONAP release X and I see dependencies with strange numbers, potentially from previous ONAP releases )and would need to be adopted by the community as well. One benefit of the staging approach is that it allows to limit version variance during a stabilization period. Staging should be limited in time, probably for a period at the end of the official release cycle when everyone's artifact are mostly ready. The Release Candidate approach is another way of achieving this I believe. Regards Christophe -Original Message- From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Friday, May 12, 2017 12:29 AM To: Andrew Grimberg ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Hi Andy, thanks for the explanation. It sounds like this will require a larger discussion on the overall versioning and release strategy across ONAP projects and artifacts. For everyone's reference, in OPEN-O we decided to keep all artifact versions in sync across projects in order to minimize the management and support burden. Under this assumption, the autorelease "mega-build" that builds everything together was a way to enforce synchronized version labels and to detec
Re: [onap-discuss] Staging repo in settings.xml
Hi Christophe, Gary, Andy, I’m trying also to build projects on a local Jenkins and I’m facing some issues related to the nexus-staging-maven-plugin. I am reaching out to clarify a few things : 1) On the nexus-staging-maven-plugin documentation page (https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin), it states that it’s mandatory to have the Nexus Repository Pro version to leverage the staging feature. Can you please confirm ? 2) Is there any – quick - workaround to build all projects and skip the staging step if we want to stick with Nexus Repository OSS version ? 3) I understand that all the staging process was meant to be temporary, and to add on Gary’s last question, what is the plan moving forward and how could we contribute to that effort ? Thanks, Sébastien On 2017-05-16, 1:30 PM, "onap-discuss-boun...@lists.onap.org on behalf of Gary Wu" wrote: Hi Christophe, Thanks for adding the historical context. If I understand correctly, the staging approach was meant to be temporary right before a release. Is a release imminent, or has that been canceled? What's the current timeline to move all the artifacts back to SNAPSHOT versioning (and remove Staging repo from build dependencies) in preparation for active ONAP development? Thanks, Gary -Original Message- From: Closset, Christophe [mailto:cc6...@intl.att.com] Sent: Friday, May 12, 2017 5:52 AM To: Gary Wu ; Andrew Grimberg ; onap-discuss@lists.onap.org Subject: RE: [onap-discuss] Staging repo in settings.xml Hi Gary, Andy, As for the OpenECOMP history, the whole original idea was also to align everyone's release number and date to a common one for the launch (the current release-1.0.0 branch). Concerns were raised in the dev teams (as you pointed below) that everyone's pace would be different eventually and that we should have a way of releasing components independently even though we have serious inter dependencies within ONAP. So instead of a MEGA build - all components have their independent release jobs building on staging. This hybrid approach somehow suited us nicely, now we did not go through the blessing process to move all these to proper release artifacts and kept moving with this in the master branch as Andy explained. I agree that it's confusing and not ideal right now (the concept of not really released 'release artifacts' is puzzling at first but we got used to it). If (and that's probably a TSC decision to make) we want to move to a fully decoupled model - which with the number of repositories growing is probably a good idea - then we should also remove the joint numbering somewhat (TSC) so that components can truly release independently. This indeed brings the issue of managing dependencies in a non-intuitive manner (I'm building ONAP release X and I see dependencies with strange numbers, potentially from previous ONAP releases )and would need to be adopted by the community as well. One benefit of the staging approach is that it allows to limit version variance during a stabilization period. Staging should be limited in time, probably for a period at the end of the official release cycle when everyone's artifact are mostly ready. The Release Candidate approach is another way of achieving this I believe. Regards Christophe -Original Message- From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Friday, May 12, 2017 12:29 AM To: Andrew Grimberg ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Hi Andy, thanks for the explanation. It sounds like this will require a larger discussion on the overall versioning and release strategy across ONAP projects and artifacts. For everyone's reference, in OPEN-O we decided to keep all artifact versions in sync across projects in order to minimize the management and support burden. Under this assumption, the autorelease "mega-build" that builds everything together was a way to enforce synchronized version labels and to detect cross-project compilation issues since everyone was building against SNAPSHOT dependencies that can change at any time. If we don't want to build against SNAPSHOT dependencies across projects, then it means that different projects may have different release cycles, and we may end up with a mix of different artifact versions for the official "ONAP Version 1" distribution. This has the benefit of breaking up the autorelease "mega-build", at the cost of having to manage and support a mix of artifact versions and differing release schedules. Can someone from ECOMP pipe in to add some historical pers
Re: [onap-discuss] Staging repo in settings.xml
Hi Christophe, Thanks for adding the historical context. If I understand correctly, the staging approach was meant to be temporary right before a release. Is a release imminent, or has that been canceled? What's the current timeline to move all the artifacts back to SNAPSHOT versioning (and remove Staging repo from build dependencies) in preparation for active ONAP development? Thanks, Gary -Original Message- From: Closset, Christophe [mailto:cc6...@intl.att.com] Sent: Friday, May 12, 2017 5:52 AM To: Gary Wu ; Andrew Grimberg ; onap-discuss@lists.onap.org Subject: RE: [onap-discuss] Staging repo in settings.xml Hi Gary, Andy, As for the OpenECOMP history, the whole original idea was also to align everyone's release number and date to a common one for the launch (the current release-1.0.0 branch). Concerns were raised in the dev teams (as you pointed below) that everyone's pace would be different eventually and that we should have a way of releasing components independently even though we have serious inter dependencies within ONAP. So instead of a MEGA build - all components have their independent release jobs building on staging. This hybrid approach somehow suited us nicely, now we did not go through the blessing process to move all these to proper release artifacts and kept moving with this in the master branch as Andy explained. I agree that it's confusing and not ideal right now (the concept of not really released 'release artifacts' is puzzling at first but we got used to it). If (and that's probably a TSC decision to make) we want to move to a fully decoupled model - which with the number of repositories growing is probably a good idea - then we should also remove the joint numbering somewhat (TSC) so that components can truly release independently. This indeed brings the issue of managing dependencies in a non-intuitive manner (I'm building ONAP release X and I see dependencies with strange numbers, potentially from previous ONAP releases )and would need to be adopted by the community as well. One benefit of the staging approach is that it allows to limit version variance during a stabilization period. Staging should be limited in time, probably for a period at the end of the official release cycle when everyone's artifact are mostly ready. The Release Candidate approach is another way of achieving this I believe. Regards Christophe -Original Message- From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Friday, May 12, 2017 12:29 AM To: Andrew Grimberg ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Hi Andy, thanks for the explanation. It sounds like this will require a larger discussion on the overall versioning and release strategy across ONAP projects and artifacts. For everyone's reference, in OPEN-O we decided to keep all artifact versions in sync across projects in order to minimize the management and support burden. Under this assumption, the autorelease "mega-build" that builds everything together was a way to enforce synchronized version labels and to detect cross-project compilation issues since everyone was building against SNAPSHOT dependencies that can change at any time. If we don't want to build against SNAPSHOT dependencies across projects, then it means that different projects may have different release cycles, and we may end up with a mix of different artifact versions for the official "ONAP Version 1" distribution. This has the benefit of breaking up the autorelease "mega-build", at the cost of having to manage and support a mix of artifact versions and differing release schedules. Can someone from ECOMP pipe in to add some historical perspective and/or the current assumptions on artifact versioning? Regarding the issue at hand (Staging in settings.xml), a better approach may be to release the upstream artifact using a version label like "1.0.0-RC0" as an intermediate Release (i.e. no longer changing) artifact. This will allow downstream projects to build against an artifact version that is truly locked-down (and not from Staging), while allowing the upstream team some flexibility to make tweaks before releasing the final "1.0.0" version. If anyone has thoughts on this topic, please jump in. Thanks, Gary -Original Message- From: Andrew Grimberg [mailto:agrimb...@linuxfoundation.org] Sent: Thursday, May 11, 2017 1:17 PM To: Gary Wu ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml On 05/10/2017 02:05 PM, Gary Wu wrote: > What's the rationale behind including Staging in the global > settings.xml? This seems unorthodox. > > I have now observed instances (e.g. sdnc/core, mso) where a clean > build in a local environment will
Re: [onap-discuss] Staging repo in settings.xml
Hi Gary, Andy, As for the OpenECOMP history, the whole original idea was also to align everyone's release number and date to a common one for the launch (the current release-1.0.0 branch). Concerns were raised in the dev teams (as you pointed below) that everyone's pace would be different eventually and that we should have a way of releasing components independently even though we have serious inter dependencies within ONAP. So instead of a MEGA build - all components have their independent release jobs building on staging. This hybrid approach somehow suited us nicely, now we did not go through the blessing process to move all these to proper release artifacts and kept moving with this in the master branch as Andy explained. I agree that it's confusing and not ideal right now (the concept of not really released 'release artifacts' is puzzling at first but we got used to it). If (and that's probably a TSC decision to make) we want to move to a fully decoupled model - which with the number of repositories growing is probably a good idea - then we should also remove the joint numbering somewhat (TSC) so that components can truly release independently. This indeed brings the issue of managing dependencies in a non-intuitive manner (I'm building ONAP release X and I see dependencies with strange numbers, potentially from previous ONAP releases )and would need to be adopted by the community as well. One benefit of the staging approach is that it allows to limit version variance during a stabilization period. Staging should be limited in time, probably for a period at the end of the official release cycle when everyone's artifact are mostly ready. The Release Candidate approach is another way of achieving this I believe. Regards Christophe -Original Message- From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Friday, May 12, 2017 12:29 AM To: Andrew Grimberg ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Hi Andy, thanks for the explanation. It sounds like this will require a larger discussion on the overall versioning and release strategy across ONAP projects and artifacts. For everyone's reference, in OPEN-O we decided to keep all artifact versions in sync across projects in order to minimize the management and support burden. Under this assumption, the autorelease "mega-build" that builds everything together was a way to enforce synchronized version labels and to detect cross-project compilation issues since everyone was building against SNAPSHOT dependencies that can change at any time. If we don't want to build against SNAPSHOT dependencies across projects, then it means that different projects may have different release cycles, and we may end up with a mix of different artifact versions for the official "ONAP Version 1" distribution. This has the benefit of breaking up the autorelease "mega-build", at the cost of having to manage and support a mix of artifact versions and differing release schedules. Can someone from ECOMP pipe in to add some historical perspective and/or the current assumptions on artifact versioning? Regarding the issue at hand (Staging in settings.xml), a better approach may be to release the upstream artifact using a version label like "1.0.0-RC0" as an intermediate Release (i.e. no longer changing) artifact. This will allow downstream projects to build against an artifact version that is truly locked-down (and not from Staging), while allowing the upstream team some flexibility to make tweaks before releasing the final "1.0.0" version. If anyone has thoughts on this topic, please jump in. Thanks, Gary -Original Message- From: Andrew Grimberg [mailto:agrimb...@linuxfoundation.org] Sent: Thursday, May 11, 2017 1:17 PM To: Gary Wu ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml On 05/10/2017 02:05 PM, Gary Wu wrote: > What's the rationale behind including Staging in the global > settings.xml? This seems unorthodox. > > I have now observed instances (e.g. sdnc/core, mso) where a clean > build in a local environment will fail unless Staging is included in > local settings.xml. This is because there are snapshot artifacts in > Nexus that have been built with a dependency on a "release versioned" > artifact which has only been staged but not yet released. This > doesn't seem right. You're correct that it's rather unorthodox. The rational was supposed to be temporary as the original intent was that each of the base projects would be doing _independent_ releases (that whole Continuous Delivery concept). The thing is that no actual release happened before ONAP started as I was being led to believe was going to hap
Re: [onap-discuss] Staging repo in settings.xml
Hi Andy, thanks for the explanation. It sounds like this will require a larger discussion on the overall versioning and release strategy across ONAP projects and artifacts. For everyone's reference, in OPEN-O we decided to keep all artifact versions in sync across projects in order to minimize the management and support burden. Under this assumption, the autorelease "mega-build" that builds everything together was a way to enforce synchronized version labels and to detect cross-project compilation issues since everyone was building against SNAPSHOT dependencies that can change at any time. If we don't want to build against SNAPSHOT dependencies across projects, then it means that different projects may have different release cycles, and we may end up with a mix of different artifact versions for the official "ONAP Version 1" distribution. This has the benefit of breaking up the autorelease "mega-build", at the cost of having to manage and support a mix of artifact versions and differing release schedules. Can someone from ECOMP pipe in to add some historical perspective and/or the current assumptions on artifact versioning? Regarding the issue at hand (Staging in settings.xml), a better approach may be to release the upstream artifact using a version label like "1.0.0-RC0" as an intermediate Release (i.e. no longer changing) artifact. This will allow downstream projects to build against an artifact version that is truly locked-down (and not from Staging), while allowing the upstream team some flexibility to make tweaks before releasing the final "1.0.0" version. If anyone has thoughts on this topic, please jump in. Thanks, Gary -Original Message- From: Andrew Grimberg [mailto:agrimb...@linuxfoundation.org] Sent: Thursday, May 11, 2017 1:17 PM To: Gary Wu ; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml On 05/10/2017 02:05 PM, Gary Wu wrote: > What's the rationale behind including Staging in the global > settings.xml? This seems unorthodox. > > I have now observed instances (e.g. sdnc/core, mso) where a clean > build in a local environment will fail unless Staging is included in > local settings.xml. This is because there are snapshot artifacts in > Nexus that have been built with a dependency on a "release versioned" > artifact which has only been staged but not yet released. This > doesn't seem right. You're correct that it's rather unorthodox. The rational was supposed to be temporary as the original intent was that each of the base projects would be doing _independent_ releases (that whole Continuous Delivery concept). The thing is that no actual release happened before ONAP started as I was being led to believe was going to happen. As downstream of the core projects wanted to only depend on a release version so that they weren't tied to the SNAPSHOTS except for when a new feature that they were developing against was only there, I was asked to add the staging repo to the profiles. Once the core projects released I was supposed to remove the staging repo from the global profiles and then anything depending on a release version really would only be depending on the actual release version. So, either the current projects need to do some sort of actual release so that the staging repos can be dropped out of the standard global profile (or at least disabled unless explicitly enabled) or all the projects need to make modifications to how they do their builds / dependencies. Lastly I have a few things that I want to point out that the current system (admittedly flawed right now) is trying to do. 1) I would rather that all projects be more decoupled in their individual releases so that things can move _faster_. The current model is trying to bootstrap into this. 2) Monster Autorelease style jobs ala ODL and Open-O have some serious flaws in that they build the entire world when each project can (and as is currently the case for ONAP) build their own staged artifacts so that any sort of simultaneous release vehicle only has to assemble and test instead of also build. The issue with having each of the individual projects doing their own staged artifacts is that they absolutely _must_ depend on release artifacts. The current model basically makes this possible. 3) I would really like for us to get away from the idea of a megalithic code drop. It means that any time we have issues with one component it blocks and potentially causes releases to slip. Tightening the releases down to the individual components means that we can on any given "release" date say that all the currently released components are part of the new release and if someone misses the window it shouldn't be so fare in the future for the next one. This is essentially how the Linux Kernel opera
Re: [onap-discuss] Staging repo in settings.xml
On 05/10/2017 02:05 PM, Gary Wu wrote: > What's the rationale behind including Staging in the global > settings.xml? This seems unorthodox. > > I have now observed instances (e.g. sdnc/core, mso) where a clean > build in a local environment will fail unless Staging is included in > local settings.xml. This is because there are snapshot artifacts in > Nexus that have been built with a dependency on a "release versioned" > artifact which has only been staged but not yet released. This > doesn't seem right. You're correct that it's rather unorthodox. The rational was supposed to be temporary as the original intent was that each of the base projects would be doing _independent_ releases (that whole Continuous Delivery concept). The thing is that no actual release happened before ONAP started as I was being led to believe was going to happen. As downstream of the core projects wanted to only depend on a release version so that they weren't tied to the SNAPSHOTS except for when a new feature that they were developing against was only there, I was asked to add the staging repo to the profiles. Once the core projects released I was supposed to remove the staging repo from the global profiles and then anything depending on a release version really would only be depending on the actual release version. So, either the current projects need to do some sort of actual release so that the staging repos can be dropped out of the standard global profile (or at least disabled unless explicitly enabled) or all the projects need to make modifications to how they do their builds / dependencies. Lastly I have a few things that I want to point out that the current system (admittedly flawed right now) is trying to do. 1) I would rather that all projects be more decoupled in their individual releases so that things can move _faster_. The current model is trying to bootstrap into this. 2) Monster Autorelease style jobs ala ODL and Open-O have some serious flaws in that they build the entire world when each project can (and as is currently the case for ONAP) build their own staged artifacts so that any sort of simultaneous release vehicle only has to assemble and test instead of also build. The issue with having each of the individual projects doing their own staged artifacts is that they absolutely _must_ depend on release artifacts. The current model basically makes this possible. 3) I would really like for us to get away from the idea of a megalithic code drop. It means that any time we have issues with one component it blocks and potentially causes releases to slip. Tightening the releases down to the individual components means that we can on any given "release" date say that all the currently released components are part of the new release and if someone misses the window it shouldn't be so fare in the future for the next one. This is essentially how the Linux Kernel operates now. They basically hold to cadence of ~6 - 7 weeks for a kernel release. If someone misses the window, well, it's only another 1.5 - 2 months out before the next one. It means that features tend to get better polish. -Andy- -- Andrew J Grimberg Lead, IT Release Engineering The Linux Foundation signature.asc Description: OpenPGP digital signature ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] Staging repo in settings.xml
Hi Andy, What's the rationale behind including Staging in the global settings.xml? This seems unorthodox. I have now observed instances (e.g. sdnc/core, mso) where a clean build in a local environment will fail unless Staging is included in local settings.xml. This is because there are snapshot artifacts in Nexus that have been built with a dependency on a "release versioned" artifact which has only been staged but not yet released. This doesn't seem right. Per my understanding, developers are typically expected to use just the Releases and Snapshots repos in their settings.xml, but not Staging. This is the case in ODL and OPEN-O, and also matches the instructions on the ONAP wiki. This makes sense since an artifact with a release version label should be definitive and final. By including Staging in settings.xml, we can no longer be sure if a "release versioned" artifact in my local environment may actually be out of date. Also, there are conflicting artifacts of the same version that exist in both Releases and Staging repos, so now the ordering of repos in settings.xml becomes an issue. It seems to me that the Staging repo should only be in the settings.xml for jobs that are pushing to Staging, i.e. autorelease jobs. The regular verify and merge jobs should only use the Releases and Snapshots repos. Furthermore, developers should not need to include Staging in their local settings.xml. Thoughts? Thanks, Gary -Original Message- From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Andrew Grimberg Sent: Thursday, May 04, 2017 7:24 AM To: onap-discuss@lists.onap.org Subject: Re: [onap-discuss] CI integration On 05/04/2017 05:43 AM, Alon Strikovsky wrote: > Guys thank you for your tips, > > One important things the we are missing is the */setting.xml/* that is > assigned to each job. > > I cannot find any trace of how they are built. > > Any tips ? > > > > Alon Greetings folks, I'm attaching a copy of the content from our global-settings managed config file. For the $project-settings files they are configured as follows: ServerIDs: ecomp-raw ecomp-releases ecomp-snapshots ecomp-site ecomp-staging nexus3.onap.org:10001 -- uid: docker / password: docker nexus3.onap.org:10002 nexus3.onap.org:10003 nexus3.onap.org:10004 In all of the cases, except the nexus3.onap.org:10001, the user attached is the one needed for that particular project to be able to push to our nexus systems The content is the default for a settings file as given by the managed configuration provider plugin. For the various environment variables, I suggest you look at the shipped logs of one of the jobs. There is a build-environment-varisbles.txt.gz file that is a dump of the final rendered environment variables. The ones that are current pushed by jenkins as part of our global configuration are currently: GIT_BASE-- ssh://ecomp-jobbuil...@gerrit.onap.org:29418/$PROJECT GIT_NO_PROJECT JENKINS_HOSTNAME LOGS_REPO_URL LOGS_SERVER NEXUSPROXY SILO SONAR (The other settings you can lookup as I suggested, but since GIT_BASE incorporates another variable it was apropos to show how it's actually configured) Please note that the global env vars are updated and modified as our needs change. I know that with some of the work that LF Release Engineering is currently doing to better align the JJB that is used by all projects is going to mean we modify how some of these variables are used as well as what variables are defined. -Andy- -- Andrew J Grimberg Systems Administrator Release Engineering Team Lead The Linux Foundation ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss