Rancher install now fully automated https://lf-onap.atlassian.net/browse/OOM-715

https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-manifest.csv

tags are different date time format for the nexus3 repo - raising separate epic on this

see daily snapshots

https://nexus3.onap.org/#browse/search=keyword%3Daai

v2/onap/aai-traversal/manifests/1.2.0-SNAPSHOT-STAGING-20171207T123455

From: Gildas Lanilis gildas.lanilis@huawei.com
Sent: Thursday, December 7, 2017 20:27
To: onap-tsc@lists.onap.org
Cc: Michael O'Brien <Frank.Obrien@amdocs.com>; GILBERT, MAZIN E (MAZIN E) <mazin@research.att.com>
Subject: Status on TSC meeting action item on tagging and branching

Hi,

This is to follow up on the Action Item raised during TSC meeting regarding questions brought up by Michael on tagging and branching.

Michael and I discussed and 2 things came up. Clarification were brought up. Nothing to worry about. We can close this action item.

Below is the summary.

• Tagging: to provide a bit of context, OMM is testing every day its latest build by taking into account all the latest Docker images available (not the Docker images that were Release on Nov 16 but the Docker images on which some teams are currently fixing defects for Amsterdam Maintenance release). These Dockers images are not yet released for general consumption. Goal is to automate as much as possible and detect as early as possible issue on Docker Images. Question is how the define latest? In current Nexus3.org (nexus-staging repo), every team is using a different name (snapshot-latest or latest or 1.2.0-snapshot-sgtagingyyyymmddtime,…). Decision: Michael to investigate with his team if there is a consistent and reliable way to determine by scripting what is latest. In case this is not possible by scripting, we will need to work with project teams to come up with a naming convention.

• Branching: For some reasons, OOM has multiple branches that are not all really necessary. Currently the team is disciplined and working on a branch named release-1.1.0 instead of Amsterdam. We agree with Michael that the team will continue working on release-1.1.0 and when we will release Amsterdam 1.0.1 on January 18, we will work with LF to remove unnecessary branches and rename nicely release-1.1.0 to Amsterdam.

Also as we had some questions, just to re-iterate that the Jan 18 Amsterdam Maintenance Release version will be 1.0.1. The scope is bugs fix only (High and Highest priority). The community is using an independent versioning numbering for its own components. This is also further explained in wiki.

Let me know if you have any questions, I will be glad to help.

Michael, keep me honest here. I have tried to summarize to key items of our discussion.

Thanks,

Gildas

is working on this.