KEP-2539: Addressing comments from #2540

[chaodaiG]

This is updating KEP-2539 based on comments from #2540

[spiffxp]

ref: #2539

[spiffxp]

/sig release
/priority important-soon
I complete misspoke during sig-testing where we initially discussed this KEP; @ameukam was recently promoted to release manager associate, not SIG TL.

We are getting close to the point where we'd like to announce some process changes this enables (less toil, more community empowerment)

In order to get this to Implementable, can someone from @kubernetes/sig-release-leads volunteer to act as approver for this on behalf of SIG Release? Alternatively, are you OK with @ameukam approving on your behalf?

[justaugustus]

A few questions...

Around graduation, it seems that if we turn this on, it's functionally a "straight to prod/GA" scenario.

Is there a scenario/trial period where we could do a "canary" prow cluster that gets the new images immediately and repos/jobs/subprojects could opt-in to test running on that/those cluster(s)? (I'd be fine w/ having the RelEng + enhancements repos trial)

What would be the implementation timeline?

[justaugustus]

This needs to be announced widely to k-dev.

[chaodaiG]

sound good, updated to also include emailing to kubernetes-dev@googlegroups.com

[justaugustus]

cc: @kubernetes/release-engineering

[spiffxp]

Is there a scenario/trial period where we could do a "canary" prow cluster that gets the new images immediately and repos/jobs/subprojects could opt-in to test running on that/those cluster(s)?

Having two prows handle the same org is very tricky, and part of what's making it difficult to plan migration from prow.k8s.io in google.com to a prow instance in kubernetes.io. So I would say probably not for prow, as part of this KEP, but we are looking into whether something like this is a feasible approach for migrating prow.k8s.io to community.

But for jobs! that's part of the changes we're proposing here... break out the monolithic bump-all-jobs-and-prow PR into distinct PRs for prow (still owned by test-infra-oncall), and for jobs (and hand ownership of these merges to... also auto-merging?). If we wanted to get fancy with bumping different paths or different images at different cadences, we could. But the goal is... that complexity (if desired) shouldn't be test-infra-oncall's concern.

As far as "run on cluster"... this KEP is independent of what gets bumped in k8s-infra-prow-build and how. I do plan on setting up autobump for it, but the components currently impacted would be greenhouse and boskos (e.g. this was a manual run I did kubernetes/k8s.io#1740). Both update on a much slower cadence.

[spiffxp]

@justaugustus are you acting as SIG Release approver for this? or are you suggesting someone from @kubernetes/release-engineering should be?

What would be the implementation timeline?

I'm going to defer to @chaodaiG for that, but I think we're capable of landing this before test freeze.

As a reminder, we have never frozen test-infra for release freezes, and nobody has provided compelling evidence for why we should (ref: kubernetes/sig-release#907). But we are absolutely not interested in causing churn while contributors need to remain focused

[justaugustus]

@justaugustus are you acting as SIG Release approver for this? or are you suggesting someone from @kubernetes/release-engineering should be?

With the addition of a loud announcement about this and clarification of when in a cycle to do this, I'm happy to approve for SIG Release.

Just tagging the team for eyes on.
...and assigning SIG TLs + Arnaud, in case they want to explicitly approve as well:
/assign @hasheddan @jeremyrickard @ameukam

What would be the implementation timeline?

I'm going to defer to @chaodaiG for that, but I think we're capable of landing this before test freeze.

As a reminder, we have never frozen test-infra for release freezes, and nobody has provided compelling evidence for why we should (ref: kubernetes/sig-release#907). But we are absolutely not interested in causing churn while contributors need to remain focused

Agreed that this has seemed to not be required in the past, but I'll let others chime in as well.

[chaodaiG]

With the addition of a loud announcement about this and clarification of when in a cycle to do this, I'm happy to approve for SIG Release.

Thank you! Updated the KEP with a loud announcement, as well as to make you the approver from SIG Release.

What would be the implementation timeline?

The real implementation of alpha phase is very trivial, could be done in an hour, so it's very flexible. Totally agree with @spiffxp that we don't want to cause any churn in test. @justaugustus what time would you think is better?

[justaugustus]

@justaugustus what time would you think is better?

@chaodaiG -- If the work is ready now, right after we cut the branch for v1.21 probably works!

[chaodaiG]

@justaugustus what time would you think is better?

@chaodaiG -- If the work is ready now, right after we cut the branch for v1.21 probably works!

Awesome! And yes I believe it's ready, just created all the PRs for implementing alpha phase:

• Prow bump: add an auto label to distinguish it from other bumps test-infra#21313 Prow autobump job run every 6 hours instead of every hour test-infra#21315, these PRs don't do any harm, can be merged today
• prow.k8s.io bumping PR automatically merged test-infra#21314 is the PR enable continuous deployment, will merge after announcement in k8s-dev community

Will announce this change on k8s-dev right after v1.21 branch is cut

[chaodaiG]

@justaugustus , @spiffxp , now that v1.21 branch was cut, I'm preparing to announce it. Quick question, what should happen first?

• Move this KEP to implementable
• Announce to k8s-dev
  Assuming the real implementation will happen after these two events

[spiffxp]

Sure, update kep.yaml with status: provisional and I'm ready to /approve

Is the intent to announce this as alpha or beta?

[chaodaiG]

Sure, update kep.yaml with status: provisional and I'm ready to /approve

Is the intent to announce this as alpha or beta?

The initial implementation is low frequency deploy at every 6 hours, which qualifies as alpha phase, so will announce as alpha

[spiffxp]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chaodaiG, saschagrunert, spiffxp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/sig-testing/OWNERS [spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment