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:
- 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.
- 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.
- 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
- We want the process for installing the latest maintenance release of ONAP to be simple and resilient
- Project uses the approved TSC process to elect to do a Project Maintenance Release
- Project implements and cherry picks their changes into the Project Repo release branch
- Project implements and cherry picks their changes into OOM repo release branch
- Project is tested by Integration
- Project tags their project repo
- This will get easier once the helm charts are moved to the project repos
- Project creates their tagged docker containers and binary artifacts in Nexus3/Nexus
- Project requests OOM to tag their repo for the incremental change to the project
- Users can git clone -b tag+1 oom.git to retrieve the consistent set of helm charts for the project
- 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
- ONAP kubernetes environment will be the current ONAP release plus the up-reved projects that participated in the maintenance release
- 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?