Page tree
Skip to end of metadata
Go to start of metadata

From the beginning, OPNFV has made releases with roughly 6 months intervals. After the forth release is out after 2.5 years, it is a good time to reconsider the release model.

Definitions

Release model

OPNFV deliverable is a set of installer instances that have a pre-determined release dates and that are pre-tested. All installer instances use mostly the same versions of the upstream packages that they install. 

Continuous integration (CI) model

OPNFV delivers an installer that pulls in the latest (stable?) versions of upstream components and configures them. Installations on different days may be different, since the upstream can change. The upstream versions are tested in OPNFV labs.

Pros and cons

Release model

(smile) The release model allows to test the installers, the components and the configuration before release. This way anyone who downloads and installs OPNFV will have some guarantees that the installation will work.

(smile) In case of difficulties, the installation is the same as anyone else's installation, so it is possible to get help from others.

(sad) Each release has overhead in testing and documentation. The more frequent the releases are, the more overhead there is, but with less frequent releases, the upstream components get old.

(sad) The OPNFV release lags the upstream development. Any bugs have to be fixed both in upstream and in the OPNFV release.

 

CI model

(smile) In the CI model, all fixes upstream are available to OPNFV. This makes it easier to work with fast moving upstream projects. All new features upstream are also available to OPNFV sooner.

(sad) In case of difficulties, it is hard to give precise fixes since the installations can be slightly different.

 

 

Mixed models?

  • Some projects follow the release model and other the CI model
  • OPNFV releases are more frequent, once a month?
  • There are stable and experimental OPNFV installations, and each project can choose to join either or both

 

  • No labels

1 Comment

  1. We need to define who the stakeholders are here, what they need, and how to support that. For example, developers in OPNFV need the maximum time available in a release to develop updates for that release. CI will enable that. Distro and platform vendors produce products that are typically stable release based, so OPNFV needs stable branch releases that are maintained for a reasonable time, for Dovetail. End-users who are experimenting with OPNFV need a reliable system, and should be able to choose a stable branch or a CI version (as with OpenStack). Generally all of the CI-use stakeholders above should be able to expect that any issues with CI will be addressed quickly - this is the normal expectation for devstack users for example and I don't see a reason that OPNFV could not do the same (most issues with the OPNFV system should be temporary upstream issues).