[Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Zvonar, Bill
Bill.Zvonar at windriver.com
Fri Aug 2 13:57:23 UTC 2019
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
More information about the Starlingx-discuss
mailing list