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

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
  • No labels