Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

Spec

This is "a smaller feature" which involves architectural change in only single component ie. some internal design refactoring etc.


  • No labels