[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
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
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@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@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 _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following: Branch: r/stx.2.0 Tag: v2.0.0.rc0 Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag... I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/ The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process. dt [0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process -- Dean Troyer dtroyer@gmail.com
Proposed next steps (to be discussed in meeting today... 1. Release Team announces a freeze on master for TBD time (see Note) 2. Scott/Dean create RC1 branch and make required build changes. 3. Scott triggers RC1 build, both ISO and Docker images. 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available. Note: Developers push changes to master and for High priority LPs also cherry pick their commit to the RC1 branch. -----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Friday, August 2, 2019 1:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following: Branch: r/stx.2.0 Tag: v2.0.0.rc0 Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag... I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/ The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process. dt [0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
From the meeting just now, Scott & Dean agreed that they can base the branch off of a SHA, so there is no need for a freeze. They will finish some script changes for this (thanks guys) and, assuming Monday's sanity is green, will start creating the branch on Tuesday. After the sanity on the RC1 branch is done, we'll announce that the branch is ready to use. More details here and at [0] on the modified sequence... 1 Start (no freeze required since we're branching from a SHA, not from Head) - on Tuesday - Dean will start at ~9:30 his time (CDT) (10:30 EDT) - assuming sanity is Green - Dean will branch from the SHA for that sanity's build 2. Scott/Dean create RC1 branch and make required build changes. - Dean will make sure he's able to do the SHA thing - this will be based on Monday's sanity, which will be based on the commits up to Sunday evening - i.e. UTC 0130 am Monday https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190805T0130 3. Scott triggers RC1 build, both ISO and Docker images. - Scott has a few script changes to do, will work to knock those off today - we agreed on these build paths - Release path .../starlingx/release/2.0.##/centos .../starlingx/release/2.0/2.0.##/centos - RC path .../starlingx/rc/2.0/centos/timestamp 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available. Note: Developers push changes to master and for Medium & High priority LPs also cherry pick their commit to the RC1 branch. [0] https://etherpad.openstack.org/p/stx-releases -----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 1:36 PM To: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Proposed next steps (to be discussed in meeting today... 1. Release Team announces a freeze on master for TBD time (see Note) 2. Scott/Dean create RC1 branch and make required build changes. 3. Scott triggers RC1 build, both ISO and Docker images. 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available. Note: Developers push changes to master and for High priority LPs also cherry pick their commit to the RC1 branch. -----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Friday, August 2, 2019 1:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following: Branch: r/stx.2.0 Tag: v2.0.0.rc0 Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag... I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/ The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process. dt [0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Nice to see this happening. One question: would the two ISOs (master, RC1) will be available at similar times? Or how is the build process to be scheduled? A.
-----Original Message----- From: Zvonar, Bill [mailto:Bill.Zvonar@windriver.com] Sent: Friday, August 2, 2019 1:56 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
From the meeting just now, Scott & Dean agreed that they can base the branch off of a SHA, so there is no need for a freeze.
They will finish some script changes for this (thanks guys) and, assuming Monday's sanity is green, will start creating the branch on Tuesday.
After the sanity on the RC1 branch is done, we'll announce that the branch is ready to use.
More details here and at [0] on the modified sequence...
1 Start (no freeze required since we're branching from a SHA, not from Head) - on Tuesday - Dean will start at ~9:30 his time (CDT) (10:30 EDT) - assuming sanity is Green - Dean will branch from the SHA for that sanity's build 2. Scott/Dean create RC1 branch and make required build changes. - Dean will make sure he's able to do the SHA thing - this will be based on Monday's sanity, which will be based on the commits up to Sunday evening - i.e. UTC 0130 am Monday https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190805T01 30 3. Scott triggers RC1 build, both ISO and Docker images. - Scott has a few script changes to do, will work to knock those off today - we agreed on these build paths - Release path .../starlingx/release/2.0.##/centos .../starlingx/release/2.0/2.0.##/centos - RC path .../starlingx/rc/2.0/centos/timestamp 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available.
Note: Developers push changes to master and for Medium & High priority LPs also cherry pick their commit to the RC1 branch.
[0] https://etherpad.openstack.org/p/stx-releases
-----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 1:36 PM To: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Proposed next steps (to be discussed in meeting today...
1. Release Team announces a freeze on master for TBD time (see Note) 2. Scott/Dean create RC1 branch and make required build changes. 3. Scott triggers RC1 build, both ISO and Docker images. 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available.
Note: Developers push changes to master and for High priority LPs also cherry pick their commit to the RC1 branch.
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Friday, August 2, 2019 1:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following:
Branch: r/stx.2.0 Tag: v2.0.0.rc0
Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag...
I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/
The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process.
dt
[0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Good point. I don't think we closed on that issue during the last release meeting. Or at least it wasn't captured in the minutes. Was there an action to talk it over with the testers? CENGN doesn't really have capacity to efficiently build both loads in parallel. They need to be serial. I would assume the testing priority will shift RC1, and we would want that load delivering at midnight EST (4 am UTC), with the master build shifting to 4am EST (8 am UTC). Call this option a. Option b is to leave master delivering at midnight EST (4 am UTC), and RC1 delivers at 4 am. Thoughts? Scott On 2019-08-05 12:58 p.m., Cabrales, Ada wrote:
Nice to see this happening.
One question: would the two ISOs (master, RC1) will be available at similar times? Or how is the build process to be scheduled?
A.
-----Original Message----- From: Zvonar, Bill [mailto:Bill.Zvonar@windriver.com] Sent: Friday, August 2, 2019 1:56 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
From the meeting just now, Scott & Dean agreed that they can base the branch off of a SHA, so there is no need for a freeze.
They will finish some script changes for this (thanks guys) and, assuming Monday's sanity is green, will start creating the branch on Tuesday.
After the sanity on the RC1 branch is done, we'll announce that the branch is ready to use.
More details here and at [0] on the modified sequence...
1 Start (no freeze required since we're branching from a SHA, not from Head) - on Tuesday - Dean will start at ~9:30 his time (CDT) (10:30 EDT) - assuming sanity is Green - Dean will branch from the SHA for that sanity's build 2. Scott/Dean create RC1 branch and make required build changes. - Dean will make sure he's able to do the SHA thing - this will be based on Monday's sanity, which will be based on the commits up to Sunday evening - i.e. UTC 0130 am Monday https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190805T01 30 3. Scott triggers RC1 build, both ISO and Docker images. - Scott has a few script changes to do, will work to knock those off today - we agreed on these build paths - Release path .../starlingx/release/2.0.##/centos .../starlingx/release/2.0/2.0.##/centos - RC path .../starlingx/rc/2.0/centos/timestamp 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available.
Note: Developers push changes to master and for Medium & High priority LPs also cherry pick their commit to the RC1 branch.
[0] https://etherpad.openstack.org/p/stx-releases
-----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 1:36 PM To: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Proposed next steps (to be discussed in meeting today...
1. Release Team announces a freeze on master for TBD time (see Note) 2. Scott/Dean create RC1 branch and make required build changes. 3. Scott triggers RC1 build, both ISO and Docker images. 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available.
Note: Developers push changes to master and for High priority LPs also cherry pick their commit to the RC1 branch.
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Friday, August 2, 2019 1:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following:
Branch: r/stx.2.0 Tag: v2.0.0.rc0
Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag...
I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/
The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process.
dt
[0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
If I don't hear any objections by end of day (8 pm UTC), I'll assume that RC1 is the testing priority. I'll implement option a. The build of V2.0 RC1 completes at midnight (4 am UTC), and the master build gets pushed back 4 hours from it's current slot. Scott On 2019-08-06 9:48 a.m., Scott Little wrote:
Good point.
I don't think we closed on that issue during the last release meeting. Or at least it wasn't captured in the minutes. Was there an action to talk it over with the testers?
CENGN doesn't really have capacity to efficiently build both loads in parallel. They need to be serial. I would assume the testing priority will shift RC1, and we would want that load delivering at midnight EST (4 am UTC), with the master build shifting to 4am EST (8 am UTC). Call this option a.
Option b is to leave master delivering at midnight EST (4 am UTC), and RC1 delivers at 4 am.
Thoughts?
Scott
On 2019-08-05 12:58 p.m., Cabrales, Ada wrote:
Nice to see this happening.
One question: would the two ISOs (master, RC1) will be available at similar times? Or how is the build process to be scheduled?
A.
-----Original Message----- From: Zvonar, Bill [mailto:Bill.Zvonar@windriver.com] Sent: Friday, August 2, 2019 1:56 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
From the meeting just now, Scott & Dean agreed that they can base the branch off of a SHA, so there is no need for a freeze.
They will finish some script changes for this (thanks guys) and, assuming Monday's sanity is green, will start creating the branch on Tuesday.
After the sanity on the RC1 branch is done, we'll announce that the branch is ready to use.
More details here and at [0] on the modified sequence...
1 Start (no freeze required since we're branching from a SHA, not from Head) - on Tuesday - Dean will start at ~9:30 his time (CDT) (10:30 EDT) - assuming sanity is Green - Dean will branch from the SHA for that sanity's build 2. Scott/Dean create RC1 branch and make required build changes. - Dean will make sure he's able to do the SHA thing - this will be based on Monday's sanity, which will be based on the commits up to Sunday evening - i.e. UTC 0130 am Monday https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190805T01 30 3. Scott triggers RC1 build, both ISO and Docker images. - Scott has a few script changes to do, will work to knock those off today - we agreed on these build paths - Release path .../starlingx/release/2.0.##/centos .../starlingx/release/2.0/2.0.##/centos - RC path .../starlingx/rc/2.0/centos/timestamp 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available.
Note: Developers push changes to master and for Medium & High priority LPs also cherry pick their commit to the RC1 branch.
[0] https://etherpad.openstack.org/p/stx-releases
-----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 1:36 PM To: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Proposed next steps (to be discussed in meeting today...
1. Release Team announces a freeze on master for TBD time (see Note) 2. Scott/Dean create RC1 branch and make required build changes. 3. Scott triggers RC1 build, both ISO and Docker images. 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available.
Note: Developers push changes to master and for High priority LPs also cherry pick their commit to the RC1 branch.
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Friday, August 2, 2019 1:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following:
Branch: r/stx.2.0 Tag: v2.0.0.rc0
Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag...
I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/
The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process.
dt
[0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi all - yesterday's sanity was green, so we'll go ahead with the plan below (assuming Dean & Scott haven't run into any roadblocks). Bill... -----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 2:56 PM To: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io> Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 From the meeting just now, Scott & Dean agreed that they can base the branch off of a SHA, so there is no need for a freeze. They will finish some script changes for this (thanks guys) and, assuming Monday's sanity is green, will start creating the branch on Tuesday. After the sanity on the RC1 branch is done, we'll announce that the branch is ready to use. More details here and at [0] on the modified sequence... 1 Start (no freeze required since we're branching from a SHA, not from Head) - on Tuesday - Dean will start at ~9:30 his time (CDT) (10:30 EDT) - assuming sanity is Green - Dean will branch from the SHA for that sanity's build 2. Scott/Dean create RC1 branch and make required build changes. - Dean will make sure he's able to do the SHA thing - this will be based on Monday's sanity, which will be based on the commits up to Sunday evening - i.e. UTC 0130 am Monday https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190805T0130 3. Scott triggers RC1 build, both ISO and Docker images. - Scott has a few script changes to do, will work to knock those off today - we agreed on these build paths - Release path .../starlingx/release/2.0.##/centos .../starlingx/release/2.0/2.0.##/centos - RC path .../starlingx/rc/2.0/centos/timestamp 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available. Note: Developers push changes to master and for Medium & High priority LPs also cherry pick their commit to the RC1 branch. [0] https://etherpad.openstack.org/p/stx-releases -----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 1:36 PM To: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Proposed next steps (to be discussed in meeting today... 1. Release Team announces a freeze on master for TBD time (see Note) 2. Scott/Dean create RC1 branch and make required build changes. 3. Scott triggers RC1 build, both ISO and Docker images. 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available. Note: Developers push changes to master and for High priority LPs also cherry pick their commit to the RC1 branch. -----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Friday, August 2, 2019 1:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following: Branch: r/stx.2.0 Tag: v2.0.0.rc0 Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag... I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/ The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process. dt [0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Tue, Aug 6, 2019 at 6:16 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Hi all - yesterday's sanity was green, so we'll go ahead with the plan below (assuming Dean & Scott haven't run into any roadblocks).
It all looks good here. I'm running one last check then we'll kick it all off... And remember, No Freeze Necessary. dt -- Dean Troyer dtroyer@gmail.com
On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote:
It all looks good here. I'm running one last check then we'll kick it all off...
And the branch is complete. No reviews were merged since the build so there are no immediate backports required. The holiday gave us a de facto freeze :) We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out. Thanks dt -- Dean Troyer dtroyer@gmail.com
Cool Dean, good stuff. Scott - over to you - when do you (roughly) think the build will be ready? Ada/Numan - please stand by for sanity. Bill... -----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Tuesday, August 6, 2019 11:50 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote:
It all looks good here. I'm running one last check then we'll kick it all off...
And the branch is complete. No reviews were merged since the build so there are no immediate backports required. The holiday gave us a de facto freeze :) We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out. Thanks dt -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Actually....over to the code reviewers! Then Zull. Then me. Scott On 2019-08-06 12:00 p.m., Zvonar, Bill wrote:
Cool Dean, good stuff.
Scott - over to you - when do you (roughly) think the build will be ready?
Ada/Numan - please stand by for sanity.
Bill...
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Tuesday, August 6, 2019 11:50 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote:
It all looks good here. I'm running one last check then we'll kick it all off... And the branch is complete. No reviews were merged since the build so there are no immediate backports required. The holiday gave us a de facto freeze :)
We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out.
Thanks dt
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Aha - so who are these code reviewers? Just want to make sure they're aware that they need to do something... -----Original Message----- From: Little, Scott <Scott.Little@windriver.com> Sent: Tuesday, August 6, 2019 12:05 PM To: Zvonar, Bill <Bill.Zvonar@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Actually....over to the code reviewers! Then Zull. Then me. Scott On 2019-08-06 12:00 p.m., Zvonar, Bill wrote:
Cool Dean, good stuff.
Scott - over to you - when do you (roughly) think the build will be ready?
Ada/Numan - please stand by for sanity.
Bill...
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Tuesday, August 6, 2019 11:50 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
It all looks good here. I'm running one last check then we'll kick it all off... And the branch is complete. No reviews were merged since the build so
On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote: there are no immediate backports required. The holiday gave us a de facto freeze :)
We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out.
Thanks dt
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Sorry, just saw Don's email now... -----Original Message----- From: Zvonar, Bill <Bill.Zvonar@windriver.com> Sent: Tuesday, August 6, 2019 12:12 PM To: Little, Scott <Scott.Little@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Aha - so who are these code reviewers? Just want to make sure they're aware that they need to do something... -----Original Message----- From: Little, Scott <Scott.Little@windriver.com> Sent: Tuesday, August 6, 2019 12:05 PM To: Zvonar, Bill <Bill.Zvonar@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Actually....over to the code reviewers! Then Zull. Then me. Scott On 2019-08-06 12:00 p.m., Zvonar, Bill wrote:
Cool Dean, good stuff.
Scott - over to you - when do you (roughly) think the build will be ready?
Ada/Numan - please stand by for sanity.
Bill...
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Tuesday, August 6, 2019 11:50 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
It all looks good here. I'm running one last check then we'll kick it all off... And the branch is complete. No reviews were merged since the build so
On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote: there are no immediate backports required. The holiday gave us a de facto freeze :)
We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out.
Thanks dt
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Final two reviews are in Zuul's hands now. -----Original Message----- From: Zvonar, Bill [mailto:Bill.Zvonar@windriver.com] Sent: Tuesday, August 06, 2019 12:16 PM To: Little, Scott; Dean Troyer; starlingx-discuss@lists.starlingx.io; Cabrales, Ada; Waheed, Numan Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Sorry, just saw Don's email now... -----Original Message----- From: Zvonar, Bill <Bill.Zvonar@windriver.com> Sent: Tuesday, August 6, 2019 12:12 PM To: Little, Scott <Scott.Little@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Aha - so who are these code reviewers? Just want to make sure they're aware that they need to do something... -----Original Message----- From: Little, Scott <Scott.Little@windriver.com> Sent: Tuesday, August 6, 2019 12:05 PM To: Zvonar, Bill <Bill.Zvonar@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Actually....over to the code reviewers! Then Zull. Then me. Scott On 2019-08-06 12:00 p.m., Zvonar, Bill wrote:
Cool Dean, good stuff.
Scott - over to you - when do you (roughly) think the build will be ready?
Ada/Numan - please stand by for sanity.
Bill...
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Tuesday, August 6, 2019 11:50 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
It all looks good here. I'm running one last check then we'll kick it all off... And the branch is complete. No reviews were merged since the build so
On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote: there are no immediate backports required. The holiday gave us a de facto freeze :)
We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out.
Thanks dt
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
I haven't seen a review for the manifest as of yet. Don't see it when I pull. Dean. Was this an oversight, or were you waiting for the others to merge before creating it? Scott On 2019-08-06 1:16 p.m., Penney, Don wrote:
Final two reviews are in Zuul's hands now.
-----Original Message----- From: Zvonar, Bill [mailto:Bill.Zvonar@windriver.com] Sent: Tuesday, August 06, 2019 12:16 PM To: Little, Scott; Dean Troyer; starlingx-discuss@lists.starlingx.io; Cabrales, Ada; Waheed, Numan Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Sorry, just saw Don's email now...
-----Original Message----- From: Zvonar, Bill <Bill.Zvonar@windriver.com> Sent: Tuesday, August 6, 2019 12:12 PM To: Little, Scott <Scott.Little@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Aha - so who are these code reviewers?
Just want to make sure they're aware that they need to do something...
-----Original Message----- From: Little, Scott <Scott.Little@windriver.com> Sent: Tuesday, August 6, 2019 12:05 PM To: Zvonar, Bill <Bill.Zvonar@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Actually....over to the code reviewers!
Then Zull.
Then me.
Scott
On 2019-08-06 12:00 p.m., Zvonar, Bill wrote:
Cool Dean, good stuff.
Scott - over to you - when do you (roughly) think the build will be ready?
Ada/Numan - please stand by for sanity.
Bill...
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Tuesday, August 6, 2019 11:50 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
It all looks good here. I'm running one last check then we'll kick it all off... And the branch is complete. No reviews were merged since the build so
On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote: there are no immediate backports required. The holiday gave us a de facto freeze :)
We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out.
Thanks dt
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
I have created the r/stx.2.0 <https://review.opendev.org/#/q/status:open+project:starlingx/manifest+branch:r/stx.2.0> branch for manifest. Please review https://review.opendev.org/#/c/674904/1 Scott On 2019-08-06 2:11 p.m., Scott Little wrote:
I haven't seen a review for the manifest as of yet. Don't see it when I pull.
Dean. Was this an oversight, or were you waiting for the others to merge before creating it?
Scott
On 2019-08-06 1:16 p.m., Penney, Don wrote:
Final two reviews are in Zuul's hands now.
-----Original Message----- From: Zvonar, Bill [mailto:Bill.Zvonar@windriver.com] Sent: Tuesday, August 06, 2019 12:16 PM To: Little, Scott; Dean Troyer; starlingx-discuss@lists.starlingx.io; Cabrales, Ada; Waheed, Numan Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Sorry, just saw Don's email now...
-----Original Message----- From: Zvonar, Bill <Bill.Zvonar@windriver.com> Sent: Tuesday, August 6, 2019 12:12 PM To: Little, Scott <Scott.Little@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Aha - so who are these code reviewers?
Just want to make sure they're aware that they need to do something...
-----Original Message----- From: Little, Scott <Scott.Little@windriver.com> Sent: Tuesday, August 6, 2019 12:05 PM To: Zvonar, Bill <Bill.Zvonar@windriver.com>; Dean Troyer <dtroyer@gmail.com>; starlingx-discuss@lists.starlingx.io; Cabrales, Ada <ada.cabrales@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com> Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
Actually....over to the code reviewers!
Then Zull.
Then me.
Scott
On 2019-08-06 12:00 p.m., Zvonar, Bill wrote:
Cool Dean, good stuff.
Scott - over to you - when do you (roughly) think the build will be ready?
Ada/Numan - please stand by for sanity.
Bill...
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Tuesday, August 6, 2019 11:50 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0
It all looks good here. I'm running one last check then we'll kick it all off... And the branch is complete. No reviews were merged since the build so
On Tue, Aug 6, 2019 at 9:10 AM Dean Troyer <dtroyer@gmail.com> wrote: there are no immediate backports required. The holiday gave us a de facto freeze :)
We did see a couple of the .gitreview updates have errors in the check queue, a recheck has cleared them so far. If that does not work, please contact me or Scott or Don and we'll try to sort it out.
Thanks dt
-- Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Ada/Numan - FYI re: build frequency... According the build team notes from last week's meeting [0], they will do 2 builds daily during the 4 week (RC1 - Release) period. [0] https://etherpad.openstack.org/p/stx-build -----Original Message----- From: Zvonar, Bill Sent: Tuesday, August 6, 2019 7:13 AM To: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io>; 'Dean Troyer' <dean.troyer@intel.com>; Little, Scott <Scott.Little@windriver.com> Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Hi all - yesterday's sanity was green, so we'll go ahead with the plan below (assuming Dean & Scott haven't run into any roadblocks). Bill... -----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 2:56 PM To: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io> Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 From the meeting just now, Scott & Dean agreed that they can base the branch off of a SHA, so there is no need for a freeze. They will finish some script changes for this (thanks guys) and, assuming Monday's sanity is green, will start creating the branch on Tuesday. After the sanity on the RC1 branch is done, we'll announce that the branch is ready to use. More details here and at [0] on the modified sequence... 1 Start (no freeze required since we're branching from a SHA, not from Head) - on Tuesday - Dean will start at ~9:30 his time (CDT) (10:30 EDT) - assuming sanity is Green - Dean will branch from the SHA for that sanity's build 2. Scott/Dean create RC1 branch and make required build changes. - Dean will make sure he's able to do the SHA thing - this will be based on Monday's sanity, which will be based on the commits up to Sunday evening - i.e. UTC 0130 am Monday https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190805T0130 3. Scott triggers RC1 build, both ISO and Docker images. - Scott has a few script changes to do, will work to knock those off today - we agreed on these build paths - Release path .../starlingx/release/2.0.##/centos .../starlingx/release/2.0/2.0.##/centos - RC path .../starlingx/rc/2.0/centos/timestamp 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available. Note: Developers push changes to master and for Medium & High priority LPs also cherry pick their commit to the RC1 branch. [0] https://etherpad.openstack.org/p/stx-releases -----Original Message----- From: Zvonar, Bill Sent: Friday, August 2, 2019 1:36 PM To: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 Proposed next steps (to be discussed in meeting today... 1. Release Team announces a freeze on master for TBD time (see Note) 2. Scott/Dean create RC1 branch and make required build changes. 3. Scott triggers RC1 build, both ISO and Docker images. 4. Ada's team runs sanity and confirm RC1 build passes sanity. 5. Release Team announces that the RC1 branch is now available. Note: Developers push changes to master and for High priority LPs also cherry pick their commit to the RC1 branch. -----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: Friday, August 2, 2019 1:19 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Release] [Build] Preparation and discussion about StarlingX release 2.0 On Fri, Aug 2, 2019 at 8:58 AM Zvonar, Bill <Bill.Zvonar@windriver.com> wrote:
Scott - if you can provide a brief summary here of what you think the steps are beforehand, that'd be great.
I ran a dry-run of the branching process this morning using the following: Branch: r/stx.2.0 Tag: v2.0.0.rc0 Tagging the branch point makes it easier later to pull a list of changes for the next RC or the release tag... I did find a couple of tweaks required in the branch-stx.sh script to account for the OpenDev change and only branching the Gerrit repos: https://review.opendev.org/#/c/674342/ The wiki pages [0] and [1] have been updated to match my current understanding (above) of the release naming and process. dt [0] https://wiki.openstack.org/wiki/StarlingX/Release_Plan [1] https://wiki.openstack.org/wiki/StarlingX/Release_Process -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (6)
-
Cabrales, Ada
-
Dean Troyer
-
Ildiko Vancsa
-
Penney, Don
-
Scott Little
-
Zvonar, Bill