Re: [onap-discuss] Staging repo in settings.xml

[Lefevre, Catherine]

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 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 <sp

Re: [onap-discuss] Staging repo in settings.xml

[Gary Wu]

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 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 peop

Re: [onap-discuss] Staging repo in settings.xml

[Closset, Christophe]

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<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

[SPATSCHECK, OLIVER (OLIVER)]

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 
> 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

[Andrew Grimberg]

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

[Gary Wu]

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) <spat...@research.att.com>; Gary Wu 
<gary.i...@huawei.com>
Cc: 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

On 05/24/2017 11:34 AM, SPATSCHECK, OLIVER  (OLIVER) wrote:
> 
>> On May 24, 2017, at 10:54 AM  EDT, Gary Wu <gary.i...@huawei.com>
>> 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

[Andrew Grimberg]

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

[SPATSCHECK, OLIVER (OLIVER)]

> 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

[Gary Wu]

#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 <gary.i...@huawei.com>; Closset, Christophe <cc6...@intl.att.com>; 
Andrew Grimberg <agrimb...@linuxfoundation.org>; 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" <onap-discuss-boun...@lists.onap.org on behalf of gary.i...@huawei.com> 
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 <gary.i...@huawei.com>; Andrew Grimberg 
<agrimb...@linuxfoundation.org>; 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 <agrimb...@linuxfoundation.org>; 
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

Re: [onap-discuss] Staging repo in settings.xml

[Gary Wu]

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 <gary.i...@huawei.com>; Andrew Grimberg 
<agrimb...@linuxfoundation.org>; 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 <agrimb...@linuxfoundation.org>; 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 <gary.i...@huawei.com>; 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. 

Re: [onap-discuss] Staging repo in settings.xml

[Gary Wu]

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 <gary.i...@huawei.com>; 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 operates now. Th

[onap-discuss] Staging repo in settings.xml

[Gary Wu]

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