The proposal

The Details

Best Practices

Best practices are functional or non-functional design patterns. Some potential examples:

• Container rootfs has to be mounted read-only
• Secret material should not be placed in logs
• Components in maintenance mode cannot be used as a dependency

(just examples, not an initial set of best-practices)

Best practices should be either a separate Jira project or a repo in RST that can be included in the documentation. The details of creation process depends on the form chosen by then community.

Anyone in the community can propose a new best practice at any time.

Best practice can be in one of below states:

• WIP
• Under review
• Waiting for approval
• Approved
• Rejected
• Removed

WIP - default state for every new BP that allows the author to work on it without bothering other people

Under review - the BP is in the review with impacted parties (Every BP should be socialized with PTL. BP that impact the architecture (functional) should be consulted with the architecture Team. BP that impacts docs should be consulted with DOC team. BP that impacts security aspects should be consulted with SECCOM)

Waiting for approval - The BP has been socialized with required parties and now it is ready to be voted by the TSC

Approved - The BP has been approved by the TSC and it should be followed by all New Code (the definition is below)

Rejected - The BP has been rejected by the TSC, which means that there is no agreement in the community that this is the right pattern to follow

Removed - The BP that has been previously in the Approved state may turn out to be out of date or impossible to follow due to some project constraints. In such case anyone may ask the TSC to revise such a BP and revoke it.

Best practices has to be followed by the new code that is arriving to the ONAP tree. The definition of new code may depend on the project thus it's recommended that every PTL clarifies the rules for his project.

For example:

In OOM project typically we consider every new chart that arrives for a review to be a new code

In DOC project a new code may be a new page or a new module

In typical java development project a new code may be new module or new microservice depending on PTL criteria.

It's advised, but not mandatory, for the PTL to ensure, as soon as resources allows, that the code that is already in ONAP repos and is under his responsibility follow all approved BP. However this is not going to be gated as long as given BP is not approved as a Global Requirement for a given release.

Global Requirements

Global requirement is an already approved  best practice, that has been chosen by the TSC to be the gating criteria for a given release.

Before every release TSC agrees on the list of BP that are view by them as High Priority Issues and should be applied to whole ONAP code base, not only to a new code.

Components that does not meet GR at Feature Freeze will be reverted back to the container version used in the previous release. This means that no new functionality can be added to this container in a given release if it doesn't meet the GR.

Feature

This is practically the same as our current "Use case". It's basically an ONAP-level functionality that impacts multiple components and is visible to the end user. The name "Feature" can be replaced with the current "Use case" if community prefers this name. This can be represented as a Jira ticket in a dedicated project or an RST page in a dedicated repo.

Feature may be in one of below states:

• WIP
• Under review
• Waiting for approval
• Approved
• Rejected
• Active
• On Hold
• In testing
• Finished
• Dropped

WIP - default state for every new feature that allows the author to work on it without bothering other people

Under review - the BP is in the review with:

• Architecture
• Requirements subcomittee
• SECCOM
• PTLs

To save submitter time, the review should happen asynchronously by default (unless submitter asked for a VCC to present) and only if subcommittee has additional questions a VCC meeting to answer them should be scheduled. Questions and doubts should be written down before the VCC.

Waiting for approval - The feature has been socialized with required parties and now it is ready to be voted by the TSC

Approved - The Feature has been approved by the TSC. Implementation may be started if the feature is put in the "Active" state before "Spec freeze" for a given release.

Rejected - The Feature has been rejected by the TSC, which means that there is no agreement in the community that this is the right change

Active - The feature is being actively worked on in a current release.

On Hold - The implementation has been started but there is no progress planned for a current release due to some constraints.

In testing - The feature is complete and is now being tested by the integration team

Finished - implemented and tested

Dropped - people lost interest in this feature

Anyone in the community can propose a new feature at any time but the implementation should be started only when Feature is Active for a given release.

A feature may be linked directly to tasks if it's relatively simple or consist of multiple specs from which every one may be tested separately in "early release model".

Spec

This is "a smaller feature" which involves architectural change in only single component ie. some internal design refactoring etc. This can really be a Jira epic that describes where associated tasks are going.

Spec is scoped for single component thus it has to be approved only by people who know this component best - PTL and his or her committers.

PTL may request additional review from subcommittees if needed.

Spec has to be marked as Active before it can be implemented. In fact it behaves similar to Features but is just smaller