[onap-tsc] tagging issues

[eric.debeau]

Hello

We still have some problems in the ONAP versioning/tagging.
In the Amsterdam version environment file 
(https://git.onap.org/demo/plain/heat/ONAP/onap_openstack.env?h=amsterdam) , 
there is still one project based on master branch.

The Docker tags are not all aligned (some start with v, other with a figure) 
and all there is still missing a lot of latest tags on Docker images under the 
DockerHub repo.

As we will jump in Beijing and then Casablanca, Dublin,  we  should have a 
latest-stable release to avoid to manage various branches and the version 
namings.

Best Regards

Eric

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] tagging issues

[Yunxia Chen]

Hi, Eric,
I agree with you: this indeed a concern.
Right now, Gildas, Ran and Gary are working with Linux foundation on this one 
and hopefully to get a solution very soon. And I also expect a stable master 
branch build, meaning we could run some basic sanity testing, more 
specifically, passing health test, running the automated vFW and vLB use case. 
And each day, we could tag what have successfully passed above testing.

Regards,

Helen Chen

From:  on behalf of Eric Debeau 

Date: Wednesday, February 28, 2018 at 10:09 AM
To: onap-tsc 
Subject: [onap-tsc] tagging issues

Hello

We still have some problems in the ONAP versioning/tagging.
In the Amsterdam version environment file 
(https://git.onap.org/demo/plain/heat/ONAP/onap_openstack.env?h=amsterdam) , 
there is still one project based on master branch.

The Docker tags are not all aligned (some start with v, other with a figure) 
and all there is still missing a lot of latest tags on Docker images under the 
DockerHub repo.

As we will jump in Beijing and then Casablanca, Dublin,  we  should have a 
latest-stable release to avoid to manage various branches and the version 
namings.

Best Regards

Eric

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Release management process is broken

[Alexis de Talhouët]

Does anyone has any input on the same?

I think it is *critical* that we can deliver tagged artifacts (whether maven, 
docker *and code*) for each of our release. Most importantly, for Beijing 
coming in a few weeks.

We had a discussion last week on the #lf-releng channel, and it seems the issue 
is identified. See raw discussion snippet bellow

tykeal  hmm I think I may know what the problem here is. The ONAP 
releases are done using the maven version plugin. The release jobs take the 
current version that gets checked out and then for the release job the version 
plugin is run to drop the SNAPSHOT name and then produce the artifacts
zxiiro  adetalhouet_: looks like you got all the points to me.
tykeal  as such gerrit doesn't have any of the released versions 
actually stored but the target tag points to the version that was checked out 
to produce the release artifacts
zxiiro  tykeal: maven version plugin should take care of removing the 
snapshot AND git tagging though if I recall.
tykeal  zxiiro: it's not being used to do the tagging
zxiiro  :/
zxiiro  looks like they are missing the step we do in ODL where we 
produce git.bundles and store it in the log server for tagging at a later date.
tykeal  ONAP release process at present is basically the following:
tykeal  daily jobs produce RC builds
tykeal  a request is made to release the builds staging repo produced 
by job XYZ
tykeal  RE looks up the staging repo from the job output
tykeal  signs the artifacts and releases them
tykeal  looks up the git sha that was checked out by the job and tags it
zxiiro  ya that's not right. they need to get the git.bundle and 
Jenkins should be producing it by creating a commit on the pom.xmls that it 
modified before the build.
tykeal  zxiiro: yes, they're missing that step because ONAP isn't using 
the release jobs that ODL created because global-jjb didn't exist when they 
implemented and they didn't want to copy the work that ODL had already done
zxiiro  even if we drop the SNAPSHOTS and tag from the same base 
commit, that produces a new sha so while it looks the same it is not identical. 
Which is why it's so important to save the git.bundles.
*   AlexAvadanii has quit (Ping timeout: 256 seconds)
*   CristinaPauna has quit (Ping timeout: 248 seconds)
tykeal  @zxiiro: I'm not saying that they're producing an updated 
commit, they're are literally tagging the commit that Jenkins checked out, not 
one with a modified pom


Alexis

> On Feb 23, 2018, at 10:58 AM, Alexis de Talhouët  
> wrote:
> 
> Hello TSC, Release management team,
> 
> I just found out our release process is somewhat broken. We should never be 
> tagging snapshot commits as releases, and tags in projects relates to 
> SNAPSHOT.
> Even more, they are multiple tags pointing to the same SNAPSHOT.
> I can see they are released artifacts in Nexus, but there is no corresponding 
> code for it, although I would have expect the tag to have the code at the 
> very specific commit used for the release.
> 
> This is a major concern, as this means it’s impossible for downstream users 
> to consume and develop their own stuff on released ONAP code (as it doesn’t 
> exist). It’s also impossible to debug issues as we don’t have the exact 
> version of the code we’re running.
> 
> Can this topic be added at the TSC next week?
> 
> Alexis

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] tagging issues

[Gildas Lanilis]

Hi Eric,

To help the discussion on tagging, I would like to indicate that tagging is 
made in multiple locations.
From what I know I see:

1)  Tagging at the repository level: that was done by LF when we had the 
first release of Amsterdam on Nov 16 and then later for the maintenance release 
in January.

2)  Tagging the docker images: As Helen pointed out, we have been working 
with numerous people and LF on this. Jira Ticket is 
here.

3)  We also have the Manifest files that record the version of the Binary 
artifacts
 and Docker 
artifacts
 once they are released

4)  Not familiar with the 
file 
you have shared in the Demo repo, but I guess this file is pulling information 
from the above.

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Yunxia Chen
Sent: Wednesday, February 28, 2018 10:41 AM
To: eric.deb...@orange.com; onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] tagging issues

Hi, Eric,
I agree with you: this indeed a concern.
Right now, Gildas, Ran and Gary are working with Linux foundation on this one 
and hopefully to get a solution very soon. And I also expect a stable master 
branch build, meaning we could run some basic sanity testing, more 
specifically, passing health test, running the automated vFW and vLB use case. 
And each day, we could tag what have successfully passed above testing.

Regards,

Helen Chen

From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Eric Debeau mailto:eric.deb...@orange.com>>
Date: Wednesday, February 28, 2018 at 10:09 AM
To: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: [onap-tsc] tagging issues

Hello

We still have some problems in the ONAP versioning/tagging.
In the Amsterdam version environment file 
(https://git.onap.org/demo/plain/heat/ONAP/onap_openstack.env?h=amsterdam) , 
there is still one project based on master branch.

The Docker tags are not all aligned (some start with v, other with a figure) 
and all there is still missing a lot of latest tags on Docker images under the 
DockerHub repo.

As we will jump in Beijing and then Casablanca, Dublin,  we  should have a 
latest-stable release to avoid to manage various branches and the version 
namings.

Best Regards

Eric

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Release management process is broken

[Gary Wu]

Usually the maven release plugin is used for this, which would:


· Checkout SNAPSHOT version poms, e.g. “1.1-SNAPSHOT”

· Update poms to release version, e.g. “1.1”

· Build and run all tests

· Commit release version poms into git repo

· Tag this “release version” commit in git

· Update poms to next SNAPSHOT version, e.g. “1.2-SNAPSHOT”

· Commit new SNAPSHOT version poms into git repo

However, this conflicts with our use of staging/RC builds since we obviously 
don’t want to commit pom changes for every RC build.

To work with staging/RC builds, the ODL method of saving git bundles for later 
tagging seems like it would work fine.  Are there any downsides to this 
approach?

Thanks,
Gary

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alexis de Talhouët
Sent: Wednesday, February 28, 2018 11:07 AM
To: t...@lists.onap.org; onap-discuss 
Subject: Re: [onap-tsc] Release management process is broken

Does anyone has any input on the same?

I think it is *critical* that we can deliver tagged artifacts (whether maven, 
docker *and code*) for each of our release. Most importantly, for Beijing 
coming in a few weeks.

We had a discussion last week on the #lf-releng channel, and it seems the issue 
is identified. See raw discussion snippet bellow

tykeal hmm I think I may know what the problem here is. The 
ONAP releases are done using the maven version plugin. The release jobs take 
the current version that gets checked out and then for the release job the 
version plugin is run to drop the SNAPSHOT name and then produce the artifacts
zxiiro adetalhouet_: looks like you got all the points to me.
tykeal as such gerrit doesn't have any of the released versions 
actually stored but the target tag points to the version that was checked out 
to produce the release artifacts
zxiiro tykeal: maven version plugin should take care of removing 
the snapshot AND git tagging though if I recall.
tykeal zxiiro: it's not being used to do the tagging
zxiiro :/
zxiiro looks like they are missing the step we do in ODL where we 
produce git.bundles and store it in the log server for tagging at a later date.
tykeal ONAP release process at present is basically the following:
tykeal daily jobs produce RC builds
tykeal a request is made to release the builds staging repo 
produced by job XYZ
tykeal RE looks up the staging repo from the job output
tykeal signs the artifacts and releases them
tykeal looks up the git sha that was checked out by the job and 
tags it
zxiiro ya that's not right. they need to get the git.bundle and 
Jenkins should be producing it by creating a commit on the pom.xmls that it 
modified before the build.
tykeal zxiiro: yes, they're missing that step because ONAP isn't 
using the release jobs that ODL created because global-jjb didn't exist when 
they implemented and they didn't want to copy the work that ODL had already done
zxiiro even if we drop the SNAPSHOTS and tag from the same base 
commit, that produces a new sha so while it looks the same it is not identical. 
Which is why it's so important to save the git.bundles.
* AlexAvadanii has quit (Ping timeout: 256 seconds)
* CristinaPauna has quit (Ping timeout: 248 seconds)
tykeal @zxiiro: I'm not saying that they're producing an updated 
commit, they're are literally tagging the commit that Jenkins checked out, not 
one with a modified pom


Alexis

On Feb 23, 2018, at 10:58 AM, Alexis de Talhouët 
mailto:adetalhoue...@gmail.com>> wrote:

Hello TSC, Release management team,

I just found out our release process is somewhat broken. We should never be 
tagging snapshot commits as releases, and tags in projects relates to SNAPSHOT.
Even more, they are multiple tags pointing to the same SNAPSHOT.
I can see they are released artifacts in Nexus, but there is no corresponding 
code for it, although I would have expect the tag to have the code at the very 
specific commit used for the release.

This is a major concern, as this means it’s impossible for downstream users to 
consume and develop their own stuff on released ONAP code (as it doesn’t 
exist). It’s also impossible to debug issues as we don’t have the exact version 
of the code we’re running.

Can this topic be added at the TSC next week?

Alexis

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc