Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Stack of Brahmaputra ======

^ Stack     ^          OS                  ^^
^ :::       ^ Ubuntu            ^ CentOS    ^
| Openstack | Kilo              | Kiko      |
| Kernel    | 3.14?             |           |
| OVS       | 2.3.0             |           |
| Qemu      | 2.3.0             |           |
| KVM       |                   |           |
| Libvirt   | 1.2.13            |           |
| ODL       | Lithium SR2       |           |
| Onos      |                   |           |


====== Discussion: Release Artifacts for Brahmaputra ======


===== Objectives =====

Objectives for released artifacts:

  * Offer users "something which consistently installs a stable state of an OPNFV release"
  * Minimize the release engineering effort around packaging and maintenance of the packaging
  * Install efficiency (efficiency of artifact download necessary to meet their needs)

----

===== Options: Release Artifacts =====

Summary of options discussed:

^ Identifier  ^ Option title                                        ^
| A.1a        | Bootable disk image per installer                   |
| A.1b        | Self-contained bootable disk image per installer    |
| A.1c        | Single bootable disk image covering all installers  |
| A.2a        | Install-documentation only per installer            |
| A.2b        | Install script per installer                        |
| A.2c        | Single install script covering all installers       |



Note: For OPNFV Arno:
  * A.1b was required
  * A.1a and A.2b were optional

Note: For OPNFV Brahmaputra : 
  * A.2b is required

TSC decision : http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-10-06-13.59.html 
VOTE: Voted on "Preference on minimum requirements on release artifacts?" Results are, A2b: 7, abstain: 1, A1b: 1 (ChrisPriceAB, 14:49:18)



==== Option A.1a: Bootable disk image per installer ====

A release is comprised of: 

  * A bootable disk image in .iso format per installer which offers an install capability for the jumphost
  * documentation / release notes

==== Option A.1b: Self-contained bootable disk image per installer ====

A release is comprised of: 

  * A bootable disk image in .iso format per installer which offers an install capability for the jumphost. The .iso also includes all artifacts that a full OPNFV system requires. There is no need for the Jumphost to have connectivity to external repositories.
  * documentation / release notes


==== Option A.1c: Single bootable disk image covering all installers ====

A release is comprised of: 

  * A single bootable disk image in .iso format covering all installers which offers an install capability for the jumphost
  * documentation / release notes

==== Option A.2a: Install-documentation only per installer ====

A release is comprised of:

  * documentation / release notes on installing OPNFV from the tagged Git repository corresponding to the release 

==== Option A.2b: Install script per installer ====

A release is comprised of:

  * "deploy.sh" script per installer which offers an install capability for the jumphost (i.e. the script creates and brings up a VM on the jumphost, which subsequently drives the installation of the OPNFV system). The "deploy.sh" script can customized, so that the configuration that is desired by the user will be installed. "deploy.sh" relies on OPNFV and upstream repositories.
  * documentation / release notes


==== Option A.2c: Single install script covering all installers ====

A release is comprised of:

  * A single "deploy.sh" script covering all installers which offers an install capability for the jumphost (i.e. the script creates and brings up a VM on the jumphost, which subsequently drives the installation of the OPNFV system). The "deploy.sh" script can customized, so that the installer and configuration that is desired by the user will be installed. "deploy.sh" relies on OPNFV and upstream repositories.
  * documentation / release notes



----


===== Options: Release Maintenance =====

Summary of approaches discussed:

^ Identifier ^ Approach title ^
| M.1 | Latest only |
| M.2a | Latest and stable branch maintenance |
| M.2b | Latest plus Service Releases for "Latest-1/stable" |
| M.3a | Latest and branch maintenance for the last k releases (k>1) |
| M.3b | Latest plus Service Releases for "Latest-n" (n=1,2..m) |

Note: For OPNFV Arno approach "M.2b" is used.

==== Option M.1: Latest only ====

Release definition and maintenance:

  * "Releases" are defined by labeling in git. No branches are created.
  * Releases are a "snapshot in time" - i.e. once a release is labeled it does not receive any further maintenance, i.e. its content is frozen and will not receive any updates or fixes. Access to a release is via its labels.
  * Bug fixes and new features are provided in a continous way.  

==== Option M.2a: Latest and stable branch maintenance ====

Release definition and maintenance:

  * "Releases" are defined by labeling in git. 
  * A release is maintained and bug-fixes are applied to a release. I.e. there are always two active branches in OPNFV:
    * "latest" - artifacts that will become the next release
    * "stable" - the current release plus fixes on top of the most recent release (i.e. on top of the labeled artifacts of the most recent release).
  * The "stable" branch will be available and stable at all times after the release until the next release.
    * Requires higher validation settings on stable for all changes

Example for this option: 
  * Brahmaputra released - Brahmaputra would be the "stable" release, C-River would become "latest"
  * Fixes for Brahmaputra would be done and committed to "stable"
  * No further maintenance for Arno would be done

==== Option M.2b: Latest plus Service Releases for "Latest-1/stable" ====

Release definition and maintenance:

  * "Releases" are defined by labeling in git. 
  * A release is maintained and bug-fixes are applied to a release until a new release comes out. I.e. there are always two active branches in OPNFV:
    * "latest" - artifacts that will become the next release
    * "stable" - the current release plus fixes on top of the released (i.e. labeled) artifacts.
  * Snapshots of the "stable" branch will be released at regular intervals as "service releases" using labels.

Example for this option: 
  * Brahmaputra released - Brahmaputra would be the "stable" release, C-River would become "latest"
  * Fixes for Brahmaputra would be done and committed to "stable"
  * At regular intervals service releases of Brahmaputra would be created
  * No further maintenance for Arno would be done

==== Option M.3a: Latest and branch maintenance for the last k releases (k>1) ====

Release definition and maintenance:

  * "Releases" are defined by labeling in git. 
  * The last k releases are maintained and bug-fixes are applied to the last k releases. I.e. there are k+1 active branches in OPNFV:
    * "latest" - artifacts that will become the next release
    * "stable" - the current release plus fixes on top of the most recent release (i.e. on top of the labeled artifacts of the most recent release).
    * ...
    * "stable - (k-1)" - the release which is (k-1) versions older than the most recent release plus fixes on top of the most recent release.
  * The "stable ..." branches will be available and stable at all times.
  * "k" would be a value defined by the TSC

Example for this option - with k=2: 
  * Brahmaputra released: Brahmaputra would be the "stable" release, C-River would become "latest", Arno would be "stable-1"
  * Fixes for Brahmaputra would be done and committed to "stable"
  * Fixes for Arno would be done and committed to "stable-1"
  * Once C-River would be released, maintenance for Arno would stop.

==== Option M.3b: Latest plus Service Releases for "Latest-n" (n=1,2...) ====

Release definition and maintenance:

  * "Releases" are defined by labeling in git. 
  * A release is maintained and bug-fixes are applied to a release until a new release comes out. I.e. there are n active branches in OPNFV:
    * "latest" - artifacts that will become the next release
    * "stable release n" - the current release plus fixes on top of the released (i.e. labeled) artifacts.
    * "stable release n-1" - the release prior to the current release plus fixes on top of the released (i.e. labeled) artifacts.
    * ...
    * "stable release m" - Release m (in case m=1, this would be Arno) plus fixes on top of the released artifacts.
  * Snapshots of the "stable" branches will be released at regular intervals as "service releases" using labels.
  * "m" would be a value defined by the TSC
Wiki

User Tools

Site Tools

Page Tools
