Skip to content

Latest commit

 

History

History
583 lines (447 loc) · 22.7 KB

README.md

File metadata and controls

583 lines (447 loc) · 22.7 KB

KEP-2853: Kubernetes repository branch rename

Release Signoff Checklist

Items marked with (R) are required prior to targeting to a milestone / release.

  • (R) Enhancement issue in release milestone, which links to KEP dir in kubernetes/enhancements (not the initial KEP PR)
  • (R) KEP approvers have approved the KEP status as implementable
  • (R) Design details are appropriately documented
  • (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors)
    • e2e Tests for all Beta API Operations (endpoints)
    • (R) Ensure GA e2e tests for meet requirements for Conformance Tests
    • (R) Minimum Two Week Window for GA e2e tests to prove flake free
  • (R) Graduation criteria is in place
  • (R) Production readiness review completed
  • (R) Production readiness review approved
  • "Implementation History" section is up-to-date for milestone
  • User-facing documentation has been created in kubernetes/website, for publication to kubernetes.io
  • Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes

Summary

Many communities, both on GitHub and in the wider Git community, are considering renaming the default branch name of their repository from master. The Kubernetes GitHub repositories is gradually renaming the default branch of our own repositories from master to main. This KEP proposes that we rename the branch for the principal code repository in the Kubernetes project.

Motivation

In the Kubernetes community and other communities, there is an effort to make all the language and terms more inclusive. One small step to make that is to change the current branch name to one that is more inclusive and does not harmful and exclusionary.

Our biggest repository is kubernetes/kubernetes, and this has a lot of open Pull Requests and several other forks, clones that use that for downstream signal or a custom build.

Changing the branch name might cause issues for downstream consumers, our contributors, and the community in general.

For that, we are creating this KEP to have a plan to address the issues and communication.

Goals

The main goal is to be more inclusive using better naming.

Non-Goals

This applies only to the main Kubernetes GitHub repository kubernetes/kubernetes. Other repositories will follow a similar approach but at their timeframe.

Proposal

  • We aim to make the change during the start of v1.25 release (spring 2022).
  • Perform a Survey to gather information on downstream consumers and how this might affects their workflow. See Survey Questions.
  • Announce the change in the kubernetes-dev and kubernetes-announcement mailing list and in a blog post. As well as use Twitter and other social media to announce.
  • Change all open Pull Requests to Draft mode (so that when we rename the branch, tests will not be triggered, and we avoid a massive queue in the CI infrastructure).
  • Update all Prow jobs that use kubernetes/kubernetes and use the master branch to listen to the main branch as well
  • Follow the guide on https://github.com/kubernetes/community/blob/master/github-management/default-branch-migration.md to rename the repository branch name.
  • After the branch rename, announce that in the mailing list
  • Update all Prow jobs that use kubernetes/kubernetes and to remove the master branch
  • Convert on demand the open Pull Requests from the Draft mode to Review ready mode

References:

Risks and Mitigations

  • Risk: The branch rename may break downstream consumers

    Mitigations:

    • Send out a survey to collect feedback and desire timeframe for the change
    • Notify the community (via email k-dev and social media) when we plan the schedule and when it is approaching the change

Survey Questions

The survey we will send out to gether information from the downstream consumer will have the following questions:

  1. On which companies behalf do you submit the response?
  2. Would a kubernetes/kubernetes branch rename affect your downstream workflow? If yes, how?
  3. How much time would you need in advance before the migration happens?

Graduation Criteria

Does enabling the feature change any default behavior?
Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?

Once we rename the branch from master to main GitHub offers the follow redirections. We don't have plans to switch back to the original name once that is renamed, and issues, if that appears, will be handled as an exception and as high priority.

What happens if we reenable the feature if it was previously rolled back?
Are there any tests for feature enablement/disablement?

Rollout, Upgrade and Rollback Planning

As soon we rename the branch we do not have plans to rollback, but instead we will fix any possible issue right away.

How can a rollout or rollback fail? Can it impact already running workloads?

N/A

What specific metrics should inform a rollback?

N/A

Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?

N/A

Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?

N/A

Monitoring Requirements

N/A

How can an operator determine if the feature is in use by workloads?

N/A

Are there any missing metrics that would be useful to have to improve observability of this feature?

N/A

Dependencies

N/A

Does this feature depend on any specific services running in the cluster?

N/A

Scalability

N/A

Will enabling / using this feature result in any new API calls?

N/A

Will enabling / using this feature result in introducing new API types?

N/A

Will enabling / using this feature result in any new calls to the cloud provider?

N/A

Will enabling / using this feature result in increasing size or count of the existing API objects?

N/A

Will enabling / using this feature result in increasing time taken by any operations covered by existing SLIs/SLOs?

N/A

Will enabling / using this feature result in non-negligible increase of resource usage (CPU, RAM, disk, IO, ...) in any components?

N/A

Troubleshooting

How does this feature react if the API server and/or etcd is unavailable?
What are other known failure modes?
What steps should be taken if SLOs are not being met to determine the problem?

Implementation History

  • 2021-11-18 Initial Draft
  • 2022-02-09 Updates based on review/feedback

Drawbacks

N/A

Alternatives

N/A

Infrastructure Needed (Optional)

N/A