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

Ildiko Vancsa ildiko.vancsa at gmail.com
Fri Aug 2 14:09:27 UTC 2019


Hi,

The regular Zoom bridge is available, feel free to use it.

Thanks,
Ildikó

Sent from my iPhone


> On 2019. Aug 2., at 15:57, Zvonar, Bill <Bill.Zvonar at windriver.com> wrote:
> 
> Hi Folks,
> 
> On the release call yesterday, we agreed to have a short follow-up meeting today to close on the steps for the release branch.
> 
> I believe we agreed on 6pm UTC (11am PST, 2pm EDT): https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190802T1800.
> 
> I'm going to assume we can use the usual Zoom bridge: https://zoom.us/j/342730236.
> 
> Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
> 
> Bill... 
> 
> -----Original Message-----
> From: Scott Little <scott.little at windriver.com> 
> Sent: Thursday, August 1, 2019 4:10 PM
> To: starlingx-discuss at lists.starlingx.io
> Subject: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
> 
> 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
> 
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss



More information about the Starlingx-discuss mailing list