stable: new release on 2020-05-06 (31.20200420.3.0)

[dustymabe]

First, verify that you meet all the prerequisites

Name this issue stable: new release on YYYY-MM-DD with today's date. Once the pipeline spits out the new version ID, you can append it to the title e.g. (31.20191117.3.0).

Pre-release

Promote testing changes to stable

From the checkout for fedora-coreos-config (replace upstream below with
whichever remote name tracks coreos/):

• git fetch upstream
• git checkout stable
• git reset --hard upstream/stable
• /path/to/fedora-coreos-releng-automation/scripts/promote-config.sh testing
• Sanity check promotion with git show
• Open PR against the stable branch on https://github.com/coreos/fedora-coreos-config
• Post a link to the PR as a comment to this issue
• Ideally have at least one other person check it and approve
• Once CI has passed, merge it

Build

• Start a pipeline build (select stable, leave all other defaults)
• Post a link to the job as a comment to this issue
• Wait for the job to finish

Sanity-check the build

Using the the build browser for the stable stream:

• Verify that the parent commit and version match the previous stable release (in the future, we'll want to integrate this check in the release job)
• Check kola AWS run to make sure it didn't fail

⚠️ Release ⚠️

IMPORTANT: this is the point of no return here. Once the OSTree commit is
imported into the unified repo, any machine that manually runs rpm-ostree upgrade will have the new update.

Run the release job

• Run the release job, filling in for parameters stable and the new version ID
• Post a link to the job as a comment to this issue
• Wait for job to finish
• Verify that the OSTree commit and its signature are present and valid by booting a VM at the previous release (e.g. cosa run -d /path/to/previous.qcow2) and verifying that rpm-ostree upgrade works and rpm-ostree status shows a valid signature.

At this point, Cincinnati will see the new release on its next refresh and create a corresponding node in the graph without edges pointing to it yet.

Refresh metadata (stream and updates)

From a checkout of this repo:

• Update stream metadata, by running:

fedora-coreos-stream-generator -releases=https://fcos-builds.s3.amazonaws.com/prod/streams/stable/releases.json  -output-file=streams/stable.json -pretty-print

• Update the updates metadata, editing updates/stable.json:
  • Find the last-known-good release (whose rollout has a start_percentage of 1.0) and set its version to the most recent completed rollout
  • Delete releases with completed rollouts
  • Add a new rollout:
    • Set version field to the new version
    • Set start_epoch field to a future timestamp for the rollout start (e.g. date -d '2019/09/10 14:30UTC' +%s)
    • Set start_percentage field to 0.0
    • Set duration_minutes field to a reasonable rollout window (e.g. 2880 for 48h)
  • Update the last-modified field to current time (e.g. date -u +%Y-%m-%dT%H:%M:%SZ)

A reviewer can validate the start_epoch time by running date -u -d @<EPOCH>. An example of encoding and decoding in one step: date -d '2019/09/10 14:30UTC' +%s | xargs -I{} date -u -d @{}.

• Commit the changes and open a PR against the repo.
• Post a link to the PR as a comment to this issue
• Wait for the PR to be approved.
• Once approved, merge it and push the content to S3:

aws s3 sync --acl public-read --cache-control 'max-age=60' --exclude '*' --include 'streams/*' --include 'updates/*' . s3://fcos-builds

• Verify the new version shows up on the download page
• Verify the incoming edges are showing up in the update graph:

curl -H 'Accept: application/json' 'https://updates.coreos.fedoraproject.org/v1/graph?basearch=x86_64&stream=stable&rollout_wariness=0'

NOTE: In the future, most of these steps will be automated and a syncer will push the updated metadata to S3.

Open an issue for the next release

• Open an issue in this repo with the approximate date in the title of the next release in this stream.
  • Add the jira label to the ticket

[jlebon]

Note when promoting configs for stable, we'll also want to set osmet: false in image.yaml since it requires the newer coreos-installer which won't be in stable yet. See coreos/coreos-assembler#1418.

[sohankunkerkar]

Promotion PR: coreos/fedora-coreos-config#382

[sohankunkerkar]

Build job is running at: https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/12469/

[jlebon]

Build job is running at: jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/12469

We don't want to start that before we merge the config PR. :)

[sohankunkerkar]

Build job is running at: jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/12469

We don't want to start that before we merge the config PR. :)

My bad
Here's the new job link:
https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/12471/

[sohankunkerkar]

Release job: https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline-release/491/

[sohankunkerkar]

OSTree commit:

$ rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/x86_64/coreos/stable
                   Version: 31.20200420.3.0 (2020-05-06T16:19:21Z)
                    Commit: b3fc3a3e8513d7e424d0ced1e2517484cb766d238951f2fdec3da2fed3522efb
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

  ostree://fedora:fedora/x86_64/coreos/stable
                   Version: 31.20200407.3.0 (2020-04-21T19:37:39Z)
                    Commit: 89e17cc21b6aa3bea8959d1e6957fda157168d57ba6805d8a36142184edc2901
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

[dustymabe]

@jlebon @sohankunkerkar Now that this has run should we revert coreos/fedora-coreos-config@88047af. Or actually we should wait until we do the next stable release probably (because in the mean time we might do a hotfix stable release). Let's add it as a comment to the issue we create in this repo for the next stable release as something to do first.

[jlebon]

Yeah, I think we can just leave it there.

Let's add it as a comment to the issue we create in this repo for the next stable release as something to do first.

The promotion step in the next stable release should automatically stomp it.

[sohankunkerkar]

PR for streams and updates metadata - #95

[dustymabe]

The promotion step in the next stable release should automatically stomp it.

ahh ok

[sohankunkerkar]

Everything looks good here.