Add release tagging

[cgwalters]

Right now we don't tag releases, and our CI doesn't gate anything.

Our first step here should be having kola or whatever actually be involved in promoting a tag.

We also need an explicit tagging/promotion model of e.g. "alpha/beta/stable".

[ashcrow]

Is there a process that was used previously that worked well we could adopt or should we do something brand new?

[cgwalters]

I'd say we should take a lot of inspiration from CL here, however, I'd label our current stream as something like buildmaster which AFAIK doesn't exist in CL. And let's say whatever passes kola automatically promotes to alpha?

This issue interacts with a lot of others, like needing structured metadata.

[bgilbert]

And let's say whatever passes kola automatically promotes to alpha?

Hah, back in the day that's how CL alpha was defined.

(Well, coretest, not kola.)

[cgwalters]

So I was playing around reading this doc and ended up doing:

$ oc tag rhcos/os:latest@sha256:3300b07069731cabd994e0aac3d0425c701fc7c2e3351f2bb1faaa5491b7573b rhcos/os:alpha
The ImageStream "os" is invalid: []: Internal error: imagestreams "os" is invalid: spec.tags[alpha].from.name: Invalid value: "os:latest": error generating tag event: imagestreamimage.image.openshift.io "os:latest" not found

Which...OK I don't quite understand that. Then I did:

$ oc tag --source docker rhcos/os:latest@sha256:3300b07069731cabd994e0aac3d0425c701fc7c2e3351f2bb1faaa5491b7573b rhcos/os:alpha
Tag os:alpha set to rhcos/os:latest.

Which worked but didn't appear to push to the registry - AIUI it's only changing the image stream?

I ended up doing:

skopeo copy  docker://registry.svc.ci.openshift.org/rhcos/os@sha256:fec31b236f72d1235fcb45d858660dca957b9144d60b07831c88e27e97ceef34  docker://registry.svc.ci.openshift.org/rhcos/os:alpha

which worked.

[miabbott]

I wanted to revisit this issue since we have made some progress in terms
of testing and gating. We should be able to use these developments to
get closer to a reasonable tagging scheme for our artifacts.

I had discussion with @cgwalters and @yuqi-zhang about the path forward and we came
out of it with the following details. We don't have to address these
all at once, but we should be able to make iterative progress towards
them.

• Whatever the tagging scheme decided, we need to apply the same tags
  to the oscontainer and the VM image artifacts (qcow2, AMI, etc).

• We need a good UX story for users/cluster operators to be able to
  identify which RHCOS they are running. Currently, users are gravitating
  to the version number (4.4837), but that is fragile because it is based
  on the Jenkins build number.

• Version numbers should be unique per build. We promote a version
  to different tags.

• An initial proposal for a tagging scheme:

  • buildmaster: freshly built from the pipeline; not tested
  • alpha: image has been successfully sanity tested in AWS; made available to OpenShift
  • stable: image has been successfully tested by OpenShift; requires feedback mechanism
    from OpenShift

• The version number should be the "binding identifier" for RHCOS

Areas for improvement:

• Utilize a JSON file to store additional metatdata
  • move away from commit.txt
  • store version number in JSON file
• Make version number less fragile
  • Increment version based on value in JSON file from previous build
• Make it easier to test the pipeline
  • Proposal: pass a parameter to the pipeline(s) to create a scratch
    directory to store artifacts (i.e. /srv/rhcos/test/micah)

Next Steps:

• @cgwalters is going to work on populating the JSON file with additional metadata
• Allow folks to weigh in on these details/proposals
• @miabbott to create additional issues/tasks around the areas of improvement

[ashcrow]

I really like this. I'm 👍 on the tagging scheme as well.

[wking]

Currently, users are gravitating to the version number (4.4837), but that is fragile because it is based on the Jenkins build number.

What do you mean, "fragile". If, say, the 4.4837 build failed, you wouldn't be able to regenerate a build with that version number, but that's the point, right? I don't think these have to be sequential. It's useful for bisection that they're monotonic, but beyond that I don't see a need for additional semantic meaning or stability here. Am I missing something?