[Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0

[Scott Little]

StarlingX is preparing for its 2.0 release.  Expected next week.

Below is a discussion of how this is to be done, and a few the the 
decisions that need to be taken.

The release team has taken a first pass at answering the outstanding 
questions. Our preferred options are indicated.


General Requirements
- Create a release candidate branch from master, preferably originating 
from the context of a green sanity.
   - Branch creation might require a brief halt of commit activity on 
the master branch.  Stay tuned.
   - more on branching below
- RC branch recieves cherry-picked patches from master until a final 
compile is declared.
- Set SW_VERSION, aka PLATFORM_RELEASE, for RC branch to 19.08 (Format 
YY.MM)
   - Retain same SW_VERSION for dot releases
- Set SW_VERSION, aka PLATFORM_RELEASE, for master branch to 19.09
- Any helm chart changes to pick up release images, not the master images?
   - answer appears to be no.  Helm charts will list the images we build
- Create a CENGN job to build the RC branch.  Daily builds until final 
compile is declared.
   - scripts are fairly generic.  In theory it's just need for a new 
master job to set customize parameters.
   - A little bit of work to set docker images tags correctly vs 
branching startagy... more below
     - Current default format would default to 
"r-${BRANCH}-centos-stable-${PUBLISH_TIMESTAMP}", but this can be 
changed.  See below
   - A release branch will test some new code paths in cengn scripts.  
Will have to monitor closely.
- Make sure the build/image retirement scripts are doing the right thing.
   - Already coded to support branching opt 2 (below)
   - Support for opt 1 will require some new scripting in CENGN

Branching startagy and content lock down
   - Desired properties of the branch strategy.
      - We can re-build the ISO release at a later date.
        - The exact context of StarlingX git trees is captured in some form.
        - Context of third party git repos is captured on a best effort 
basis.  e.g. capture tag or sha (an assume they are stable), but not 
cloning gits.
        - Leverage the 'revision' field for all repos in the manifest.
      - We can rebuild our docker images at a later date... I don't 
think we fully know how to do this yet.
        - lock down the base centos image, and yum, if possible
          - Need tooling changes for this
          - Need to reference centos docker image by sha, not tag.
          - Probably need to hack the yum configuration as well, point 
it to cengn.
            - The build of stx-centos points to cengn repo for yum 
update. The loci build of images, however, also uses upstream sources. 
Otherwise, we would need to include all RPMs used for those images in 
the LST files
        - lock down our inputs from PYPI as best we can
          - Find all files named *stable_docker_image, field 
'PIP_PACKAGES=' needs to use syntax like ... e.g. panko==5.0.0
          - inputs can be found in piplst files   e.g. 
$MY_WORKSPACE/std/build-images/tis-networking-avs-heat-centos-stable.piplst
          - All python modules (non-starlingx) installed would need to 
be in the base wheels.cfg, which also updates the upper-constraints.txt 
in the tarball to restrict the installed version.
        - Lock down rpms feeding into docker images if possible.
          - Find all files named *stable_docker_image, field 
'DIST_PACKAGES=' needs to use syntax like ... e.g. 
bash-4.2.46-31.el7.tis.4.x86_64
          - inputs can be found in rpmlis files   e.g. 
$MY_WORKSPACE/std/build-images/tis-networking-avs-heat-centos-stable.rpmlst
          - ALL 'tis' packages found in rpmlst must be listed in 
DIST_PACKAGES

   - We don't have the power to branch and tag all repos.
     - Some of the work needs to be done by further locking down the 
manifest on specific tags/shas
     - Do we store the locked down manifest as tagged copy of 
default.xml, or use versioned file names xml?

   - What is the basic format of our branchs and tags
     - YYYY.MM   i.e. date like   as use by to 2018.10 release
     - 2.0       i.e. a release version
     - Current CENGN scripting uses the date format, release format 
requires scripting changes, but nothing major.
     - I'm always eager that a release branch be clearly distinguished 
from a dev/feature branch.  Currently CENGN looks for YYYY.MM.  Is it 
safe enough to look for anything starting with a number?
     - Release Team recommends the release version format be as follows
       - branch:  r/stx.2.0
       - tag:     v2.0.0

   - Opt 1 - Single RC branch.  Tags mark dot releases -- preferred by 
Release Team
     - A single branch is used to stage commits for both initial release 
and all subsequent dot releases
     - Branch name is r/stx.2.0 ... applies to starlingx repos.
     - Tags for each dot release.
       - v2.0.## ... for starlingx repos
       - v.stx.2.0.## ... for starlingx-staging repos.  Note: 
starlingx-staging may have inherited version tags from an upstream 
project that we must not collide with
     - Git lock down via creation of a uniquely named manifest 
(v2.0.##.xml) rather than default.xml.  In this manifest we specify tags 
or shas for each git.
     - We may need to halt commits to the staging branch, or at least 
the manifest git, when a dot release is imminent and we are waiting on 
test results.
     - New scripting required on CENGN for load and docker image retirement

   - Opt 2 - Single RC branch. Fork a branch to lock down a dot releases
     - A single branch is used to stage commits for both initial release 
and all subsequent dot releases
     - Branch name of staging branch is rc/stx.2.0 ... applies to 
starlingx repos.
     - When a dot release is declared, fork a release branch from the 
staging branch (r/stx.2.0.##).  Only commits permitted are to lock down 
the manifest.
     - Can still tag as in opt 1, but not required.

   - Opt 3 - new RC branch for each dot release (waterfall)
     - Branch name is r/stx.2.0.0 ... applies to starlingx
     - Final commit is to lock down the git manifest (default.xml)
     - Next dot release forks from the prior dot release, using the 
commit prior to manifest lock down.
     - Can still tag as in opt 1, but not required.



Docker image labeling:
   - A new set of docker images for each dot release
   - Probably don't need to distinguish release from release candidate 
as this is hidden within the helm charts.
   - Probably don't need to distinguish dot releases.  Again it is 
hidden by the helm charts.
   - Docker image tagging options ...

     r-2.0-centos-stable.0
     2.0-centos-stable.0
     r-2.0-centos-stable-${PUBLISH_TIMESTAMP}.0
     2.0-centos-stable-${PUBLISH_TIMESTAMP}.0    <--- preferred by 
Release Team ?
     r-2.0.##-centos-stable.0
     2.0.##-centos-stable.0
     r-2.0.##-centos-stable-${PUBLISH_TIMESTAMP}.0
     2.0.##-centos-stable-${PUBLISH_TIMESTAMP}.0


Cengn publication path:
   - Release path
     .../starlingx/release/2.0.##
     .../starlingx/release/2.0/2.0.##     <-- Preferred by Scott

   - RC path
     .../starlingx/rc/2.0/timestamp       <-- Preferred by Scott for opt 1
     .../starlingx/rc/2.0.##/timestamp
     .../starlingx/rc/2.0/2.0.##/timestamp