Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release, documentation, tools: Expand patch management support to the previous two minor versions #8805

Merged
merged 1 commit into from
Nov 9, 2017

Conversation

jpbetz
Copy link
Contributor

@jpbetz jpbetz commented Nov 1, 2017

As part of a larger effort to align the supported etcd versions with versions of etcd kubernetes supports, we propose extending the officially supported etcd versions from one previous minor release version to two.

Background / Rationale:

Current state:
etcd-current

Aspirational State:
etcd-desired

(Note that kubernetes will always lag by at least 1 minor etcd release version due to the quarterly release cadence of both projects)

How can we make progress toward the aspirational state? For kubernetes supported versions, move trailing edge forward with a deprecation policy of older etcd versions that is enforced by kube-apiserver, and move the leading edge forward with an adoption policy and schedule regular etcd upgrades supported with automated test and upgrade tooling. Establish better alignment with the actively maintained etcd version window by introducing patch management of etcd versions in use by kubernetes.

The focus here is alignment with the actively maintained etcd version window.

Resourcing:

Supporting an additional release branch takes real engineering effort beyond what we can reasonably ask CoreOS to be soley responsible for. For this to work, the community needs to pitch in and be involved.

I volunteer to take on the 3.1 and 3.2 release branch patch management duties. As qualification I offer my patch manager experience from kubernetes 1.8, and my etcd contributions, for review.

For 3.3+ we will identify patch managers from the community. As an assurance that this position will not go unmanned in the foreseeable future, @jpbetz, @cheftako and @mml are already available, and we expect other engineers to be available in the near future.

Tooling:

cherrypick script: This PR ports the kubernetes cherrypick script over to etcd to help automate the cherrypick process. Is this needed? Previous etcd has cherrypicked commits without introducing a PR to track them. The potential benefit of the PR is to facilitate automated testing. But if this adds too much additional process to etcd patch release management, I can remove the tool from this PR. Feedback welcome. Example usage to cherrypick PR 12345 to the release 3.2 branch:

hack/patch/cherrypick.sh origin/release-3.2 12345

needs-backport labels: With only one supported release branch needs-backport could always be interpreted to mean that a PR merged to master needed to be cherrypicked to the previous release. With multiple supported releases, we need to allow a backport request to specify which releases a PR needs to be backported to. We will add needs-backport-<major>.<minor> labels to facilitate this.

semaphore support for 3.1: Semaphore support was backported to 3.2 by 2f74456 . We'll do the same for 3.1, see #8807.

@gyuho
Copy link
Contributor

gyuho commented Nov 2, 2017

Q. Do you have example commands to use hack/patch/cherrypick.sh?

LGTM. Thanks!

/cc @xiang90

@jpbetz
Copy link
Contributor Author

jpbetz commented Nov 2, 2017

@gyuho The help output shows a couple examples, To cherrypick PR 12345 to the 3.2 branch, I would typically do something like:

hack/patch/cherrypick.sh origin/release-3.2 12345

This will create a PR, which can then be tested by travisCI and semaphore.

It's also possible to cherry pick multiple PRs at once:

hack/patch/cherrypick.sh origin/release-3.2 12345 12346 ...

@gyuho
Copy link
Contributor

gyuho commented Nov 3, 2017

c.f. #7308

@xiang90
Copy link
Contributor

xiang90 commented Nov 8, 2017

I am on board with extending the support to two minor versions for two reasons:

  1. etcd itself is maturing enough so that two minor releases wont diverge too much except new features
  2. we get @jpbetz and others from google committed to help

@xiang90
Copy link
Contributor

xiang90 commented Nov 9, 2017

@jpbetz Can you provide a simple readme file for the cherrypick tool? I think this PR is ready to merge.

@jpbetz
Copy link
Contributor Author

jpbetz commented Nov 9, 2017

@xiang90 Added.

@xiang90
Copy link
Contributor

xiang90 commented Nov 9, 2017

lgtm

@xiang90 xiang90 merged commit 75c7e62 into etcd-io:master Nov 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants