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@windriver.com> Sent: Thursday, August 1, 2019 4:10 PM To: starlingx-discuss@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@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss