Proposal on TSC policy for ONAP release Maintenance 2019-01-10 DRAFT!!!!!!!!!!!

Introduction This is a proposal to create a TSC policy regarding maintenance for security and maintenance patches. It covers: For how long the ONAP release should be maintained. Minimum requirements that drive a maintenance update. The structure is firstly a discussion on the motivation, then the proposed text as the policy.

Proposal Motivation There is a need for a clear maintenance strategy in ONAP releases that everybody understands. The proposal shall respect the already agreed version naming strategy, which is described (in more detail that decided) here: The ONAP Release Versioning Strategy (link). The Release Versioning strategy describes: Major Releases X.Y.Z; where X is the major release number. Enhancement Release, where the Y represents the enhancement release number of the major release (a.k.a Minor release) Service release where Z indicates the service release number (a.k.a patch release). For a security vulnerability: ONAP has security vulnerability management procedures: link There is a requirement to release the fixes to public ally known vulnerabilities within 60 days. Source: CII badging passing level “There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days” From the security sub-committee perspective, we should fix our own vulnerabilities within 60 days of it being reported. For a vulnerability to have been fixed, it is release by the specific project into the relevant repository. This doesn’t imply an ONAP release.

Proposal Motivation Maintenance fixes Aside from security fixes, there may be other bugs that are reported and should be corrected if agreed by the project. For both maintenance and security patches We need to decide whether to backport the fixes and for how many releases. Currently ONAP works on a 6 month release cadence. If/when we move towards release less then this policy would have to be updated. We need to balance the effort of which releases to maintain.

Proposal Motivation Summary Major Minor Patch Rel X+1 How many “Major” releases to maintain. Of which, How many “minor” releases to maintain Of which, how many “patch” releases to maintain. Rel X.Y.Z Rel X.y.z Rel X.Y.z Rel X.Y.Z-1 Rel X.Y-1.z Rel X.Y-1.Z Rel X-1.y.z Rel X-1.Y.Z Rel X-1.Y.z Rel X.Y-1.Z-1 Rel X-1.Y.Z-1 Rel X-1.Y-1.z Rel X-2.y.z Rel X-2.Y.z

Discussion - Maintenance Of a “minor” release (which can have several patch releases), A patch release is to fix an issue, not to add new functionality. There is no motivation to fix an issue in a previous patch. Proposal: Of a minor release, only the latest patch release is maintained and considered valid for identification of trouble reports and security issues. Of a “major” release (which can have several minor releases). Proposal: Follow the same approach. For a major release, the latest Minor release is maintained. The latest patch level is valid for trouble reports and security issues. For the number of major releases. Maintaining many major releases is extra work on design and test. Propose a phased approach: Initial and current approach: Only the latest Major release is maintained. Increased Deployment approach (timing decision to be made by the TSC). The latest release and the previous major release is maintained.

Discussion - Criteria The planning and criteria for a major release is already set by the TSC. No proposed change to this. The planning and criteria for a minor release is already set by the TSC. No proposed change to this. This is minor additional functionality Patches and fixes across many projects The criteria, planning and signoff of a patch release is required.

Patch release request The TSC can decide a patch release: Upon request or As per any TSC decision. One or more PTLs can request a patch release to solve: To address a major bug To address a security issue. The request is made via the Regular TSC meetings: Email to TSC Or Request discussion via placing on the TSC agenda. Release Criteria: The relevant projects must do the individual release activities. Docker, documentation, etc The relevant projects must pass pairwise testing. Integration regression test of release use cases is performed.

Individual project release A project can perform an individual project release at any time. This may or may not be included in a ONAP release How Request approval from the TSC. Email to the TSC or request agenda time at a TSC meeting Release criteria In the request to the TSC, a testing proposal must be included to ensure quality. This maybe, for example, local testing, pairwise testing, regression testing, etc depending on the changes made.

Patch Release motivation/criterial Motivation and criterial: To fix address a severe or high “bug” or to address a security issue. A sever bug is an issue that causes the projects deliverables to: Be unstable Not perform the agreed use cases or functionality. A high bug is an issue that causes the projects deliverables to be: Not perform as expected or described as part of the release. The decision as to what is sever or high is considered to be a project decision. The issue submitter can raise the issue to the TSC if there is a difference of opinion..

Proposal Motivation A maintenance period of 12 months would likely provide sufficient time for all downstream activities to adapt. This would imply maintenance of both the current release (release N) and release N-1. However, feedback from the PTL meeting held on Monday 6th August 2018, this was considered too high a load for the projects at this stage, hence after feedback from the PTLs, it was considered to have maintenance only for release (N). Note: Release (n) refers to the latest stable release. It is a good idea of sever (and high?) bugs are fixes as a maintenance activity. This implies that that we need a definition of sever and high bugs and a way to make this decision A sever bug is an issue that causes the projects deliverables to: Be unstable Not perform the agreed use cases or functionality. A high bug is an issue that causes the projects deliverables to be: Not perform as expected or described as part of the release. The decision as to what is sever or high is considered to be a project decision. The issue submitter can raise the issue to the TSC if there is a difference of opinion..

Proposal Motivation Project release vs ONAP release. A project can perform a release to the repositories without an ONAP release. Its too early to mandate the need of ONAP maintenance releases. This is still best left to a TSC decision for that release, on a per release basis. Given the above, the idea is to create a proposal that describes: ONAP Projects (e.g. SO, DCAE, ….) are maintained for the latest release (called release n) and at a later date, the previous release (termed release n- 1). An ONAP project must perform a project release within 60 days of: Identification of a new vulnerability From the release of a new known sever or high known vulnerability Reporting of a new sever or high bug. This must be backported for the agreed supported releases. A project release does not imply a ONAP release.

Proposal Motivation When having a project release without an ONAP release, we have to agree on what quality steps are required: Ensure that health checks and all the regression tests have been successfully performed. Depending on the changes, Stability tests might be required.

This slide is intentially left blank

Proposal for TSC policy TSC Policy: ONAP Maintenance: Definitions: ONAP Release: An ONAP release is the release of a set of artifacts from the ONAP projects that is collectively release together ONAP Project Release: An ONAP project release is a release of artifacts from a specific ONAP project. Explanatory Note: ONAP projects are listed in the ONAP wiki under approved ONAP projects. An ONAP project can have releases corresponding to the ONAP releases (e.g. Amsterdam, Beijing). Latest current release: Refers to the latest ONAP project release, and in particular to the major revision. A sever bug is an issue that causes the projects deliverables to: Be unstable Not perform the agreed use cases or functionality. A high bug is an issue that causes the projects deliverables to be: Not perform as expected or described as part of the release.

Proposal for TSC policy TSC Policy: ONAP Maintenance: ONAP Maintenance Policy: An ONAP project is required to perform a maintenance release to support the following: To ensure that there are no known sever or high vulnerabilities greater than 60 days old To ensure that a fix for new sever or high vulnerability is release within 60 days To ensure that sever bugs are fixed within 60 days. The ONAP project applies the patches to the latest current major release (Release N) ( and later upon new TSC decision the previous latest major release (Release N-1)). The ONAP projects decide whether an issue is a Severe Issue, High Issue or other. The issue requester, if s/he disagrees with the project decision can request a decision from the TSC by: Sending an email to the TSC with the subject: “Issue Priority Decision Request” Preparing the decision motivation material for part of the TSC agenda. 1 weeks notice is required. Projects can request to the TSC to have a individual project release or a ONAP release. Email to the TSC or request agenda time at a TSC meeting, including testing proposal The TSC will decide to proceed with an individual project release or a overall ONAP release.

Proposal for TSC policy Individual project release criteria Individual project release activities have been performed Health test and relevant pairwise testing is performed. Documentation is updated. ONAP project release criterial Individual project release and in addition Regression test of the release use cases performed by the integration team.

Proposal for TSC policy Questions: How to do the cryptographic signing for an individual project release that doesn’t have a related ONAP release.