[sig-release] Umbrella issue for a job that signs artifacts and uploads them to a GCS bucket

[dims]

Currently we need googlers to build, sign and upload deb/rpm artifacts. We need a prow job(s) that can do this. Ones that can be triggered by the sig-release team when they cut the release.

• Find OWNERS for the deb and rpm definitions and associated scripts.
• Define policy for dependencies are named inside the deb/rpm definition metadata
• We need a CNCF owned signing key. (We need to build a web of trust that signs this key, until then we can just use a temporary key, see kubernetes/kubernetes#70132)
• We need one or more GCS buckets for storing the artifacts (talk to wg-k8s-infra)
• Another GCS bucket for staging build artifacts pending approval
• We need a directory structure of how we would store the artifacts (to accomodate daily/nightly in addition to what we do today)
• Ability to Inspect staged artifacts (manually? automatically?) to ensure compliance with community-approved release process
• We need a trusted cluster for the job(s) (talk to wg-k8s-infra. The signing key will need to be loaded onto the cluster so the jobs can access it)
• We need a way to trigger the jobs (git-ops style, need a design for the yaml files, guessing we will need the SHA's for the k/k, k/release repos and version numbers)
• Ability for these jobs to Migrate approved release artifacts to GCS bucket for approved builds
• Add job definitions in test-infra to run the jobs in the trusted cluster

[dims]

cc @timothysc
/sig release

[timothysc]

/assign @akutz

[justaugustus]

/priority critical-urgent
/milestone v1.15

[tpepper]

This covers a set of mechanism points, but our current issue is largely one of policy in my opinion.

What dependencies are named inside the deb/rpm definition metadata? Are they specified as '=' to a version, '>=' to a version, or without a version? If versioned, do we insure all non-archived packages have the highest preferred version (re-packaging old builds to enforce fresh dependency versioning), or do we only build and publish new Kubernetes versions with the then freshest dependency version? Do we reap/archive older packages from the repos?

For any of these intended choices of package build and publication, we need documented criteria for the choice makers...when and why do they bump a piece of metadata and what all must follow from that.

By building tools not backed in a process which itself is not backed by a shared knowledge and intent in people, we aren't changing much. Changing the tools alone does not change the underlying problem. To do that we need to understand what people do/need, define process that supports them, and build tooling that automates the process. In that order, not the opposite order.

[timothysc]

@tpepper add it to the list.

[dims]

@timothysc @tpepper i added it as item number 2, presumably the OWNERS from item number 1 will help define this policy.

[akutz]

Hi @tpepper,

I could be mistaken, but I believe the intent of documenting the issue is to facilitate a discussion that results in a community-approved, well-documented approach. At that point it is up to the community to actually participate and follow through on their agreement, which the correct processes built on the proper tooling can help ensure. For example, a staging area for artifacts that are inspected prior to being published could validate that the community-approved release process was followed.

To that end, @dims, I would like to suggest adding the following to the above checklist:

• GCS bucket for staging build artifacts pending approval
• Inspect staged artifacts (manually? automatically?) to ensure compliance with community-approved release process
• Migrate approved release artifacts to GCS bucket for approved builds

[akutz]

Hi All,

I'm wondering...should this issue be a KEP? With all due respect to @dims, should the above list be a foregone conclusion on the prescribed process? As @tpepper said, the process needs community buy-in, or the whole things falls flat. To that end, doesn't it make sense to socialize the design and discussion in the manner which other K8s features are handled?

[justaugustus]

@akutz -- I can draft one.

[dims]

@akutz added slight variations of the 3 points to the list.

@akutz this is a brain dump from my experience, AFAIK, there has never been a full workflow with steps proposed, this is the attempt (not trying to push for this to be authoritative)

@justaugustus thanks! please go for it.

[dims]

@akutz we also have a tendency to go off into the weeds very quickly, so hopefully a check list will help inform the KEP :)

[justaugustus]

/assign @justaugustus @tpepper