Community support for building releases (anago)

[jbeda]

It should be possible and documented for privileged developers to create "unofficial" releases that mirror the official release process. This should include container images, debs/rpms and release download locations.

Not only will this let others contribute to these tools, but it will allow those working on install tools (like kubeadm) to test the entire flow before we integrate everything at release time.

Anago also just doesn't work if you aren't a Googler. I'm going to be looking to address some of those issues also.

[jbeda]

I'll update this comment as I find issues:

Issues:

• annoying --basedir defaults to /usr/local/google/$USER. This is a goobuntu-ism that shouldn't be in this script. At the very least we should have a better error here as this isn't writable on most systems and we only error out after picking a build (slow).
• Users cannot override GCRIO_REPO.
  • Also, this should probably default to something that is writable to the user. A better default would be the repo that goes with the default project.

[mwielgus]

This will be also needed for the process described in kubernetes/community#126.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[cblecker]

/remove-lifecycle stale
This is still relevant.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cblecker]

/remove-lifecycle stale
/lifecycle frozen

This is still needed.

[tpepper]

/cc @calebamiles
/cc @BenTheElder

Can we get a short list of remaining to-do's here? This is almost done right? We've got non-Google branch managers now for 1.11.x and 1.12, so any final issues should get worked through.

But also we need a next level issue for documenting the back end machinery and plumbing so it's maintainable by non-Googlers. If gcb makes for a push button that's usable by community release team folks, we still should aspire to the machinery also being more community supported and that will start with documenting what metadata feeds what machinery to generate what artifacts, and probably also should add test cases on artifact creation/publication so SIG-Cluster-Lifecycle's not pointing out that some part of the artifacts didn't build/publish correctly.

[BenTheElder]

I don't have any major updates or a list of to-dos other than I know the owners are working on fixing some of this, and that push-button GCB should work for the release managers, Google or otherwise for Anago at least AFAIK. My understanding is that it had already, but we regressed a bit WRT the docker images and that is being fixed.

I'd tend to agree on all of those points. I'll hopefully defer to Caleb for the moment on a more specific list.

[justaugustus]

/assign @tpepper @justaugustus @timothysc @dims
/milestone v1.15
/priority critical-urgent
/area release-eng

[justaugustus]

/remove-priority critical-urgent

[justaugustus]

We're moving the needle here and I'll have a write-up for this in 1.18.

/unassign @timothysc @david-mcmahon
/milestone v1.18

[justaugustus]

I'm closing this out, as I think we've served much of the intent of the original request.

• Container images are now build on community infrastructure: https://github.com/kubernetes/k8s.io/tree/master/k8s.gcr.io
• anago has been removed and reimagined in Golang as krel

For stories on artifact management (including debs/rpms), see this epic: kubernetes/sig-release#1372

And this project board: https://github.com/orgs/kubernetes/projects/48

deb/rpm tooling in progress here: #1027

/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

I'm closing this out, as I think we've served much of the intent of the original request.

• Container images are now build on community infrastructure: https://github.com/kubernetes/k8s.io/tree/master/k8s.gcr.io
• anago has been removed and reimagined in Golang as krel

For stories on artifact management (including debs/rpms), see this epic: kubernetes/sig-release#1372

And this project board: https://github.com/orgs/kubernetes/projects/48

deb/rpm tooling in progress here: #1027

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[BenTheElder]

anago has been removed and reimagined in Golang as krel

And more importantly both have been executed by non-googlers, we have had releases without googlers for some time now *

* Unlike the rest of the release, for debian / RPMs packages this is not the case. The community continues to rely on google's package host. #1027 is linked there, but doesn't seem to cover that. Currently a community member could build a deb/rpm (sources are public, no dependency on infrastructure in particular) but in practice they are built + signed by my team and uploaded to Google's package host still. I believe this should be tracked somewhere, as it ultimately still requires Googlers to fully ship a release.

[justaugustus]

I believe this should be tracked somewhere, as it ultimately still requires Googlers to fully ship a release.

Tracked on the Artifact Management project board as #281.

[BenTheElder]

Thanks Stephen! ❤️ That's exactly what I was looking for 👍

Also want to add: We don't mind doing this in the slightest, my team is happy to help! but I believe for the future of the project it is best to make sure releases in particular are a common effort with ~neutral access and publicly auditable infra (config in git like the rest of our wg-k8s-infra / SIG testing / release efforts).

(also for context: I'm certain @justaugustus beleives this too :-), more of a comment for anyone reading along)

[justaugustus]

@BenTheElder -- Right you are!

My biggest focus for v1.21 is refining the plan around artifact management on all axes (roughly in order of what's already been started):

• Cleaning up image promotion tooling/processes
• Continuing the file promotion work in earnest
• deb/rpm generation, signing, hosting

One of the first things I'm planning is making it faster/easier for the @kubernetes/build-admins to sign and publish.
I already have a branch in progress and I'll tag you on the PR when it's closer.