WORK IN PROGRESS

This page will describe the process to be used for a subset of ONAP projects to artifacts for a maintenance release targeted at security and high priority bug fixes that are not part of a full ONAP maintenance where all repositories are tagged.

The intent is that if only one project has to issue a fix that the process for updating the gerrit tag is minimized and we dont have to ask all projects to do a tagging effort if we are simply re-using their existing tag.

There are a few complications to this:

1. Some projects use a git clone -b "gerrit tag" project.git approach to pull configuration scripts into their containers for things like creating the database schema. The "gerrit tag" is generally set in a master oom helm chart and would need to be project specific rather than a global tag for all repositories. This can be done as projects need to do a maintenance release or as part of the next big change to their OOM helm charts.
2. The OOM helm chart repository is tagged so the process to pull a consistent set of helm charts via git clone -b "gerrit oom tag" oom.git needs to work.
3. The OOM helm charts today have the docker image reference which would be changing for a project that has a new artifact from project-container:A.B.C to project-container:A.B.C+1
4. We want the process for installing the latest maintenance release of ONAP to be simple and resilient

  Overall Process

1. Project uses the approved TSC process to elect to do a Project Maintenance Release
2. Project implements and cherry picks their changes into the Project Repo release branch
3. Project implements and cherry picks their changes into OOM repo release branch
4. Project is tested by Integration
5. Project tags their project repo 
   1. This will get easier once the helm charts are moved to the project repos
6. Project creates their tagged docker containers and binary artifacts in Nexus3/Nexus
7. Project requests OOM to tag their repo for the incremental change to the project

Result

1. Users can git clone -b tag+1 oom.git to retrieve the consistent set of helm charts for the project 
2. Installation of ONAP will use the project charts with gerritBranch values that are project_tag+1 for the update project and project_tag for the unaffected projects
3. ONAP kubernetes environment will be the current ONAP release plus the up-reved projects that participated in the maintenance release

TBC

• Will there be pairwise-testing requirements for the projects being updated?
• Will there be documentation requirements for the projects being updated?
• Could there be multiple single-project/subset-of-projects releases overlapping/concurrently?
• Is there restriction on what cannot be included in a project maintenance release? Who will enforce it?