[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