Plan to release etcd v3.5.14

[jmhbnz]

What would you like to be added?

What would you like to be added?

The etcd patch release criteria has been met for our release-3.5 stable release branch so we should release v3.5.14.

The list of commits included since the previous release is: v3.5.13...release-3.5

Work in progress CHANGELOG is: https://github.com/etcd-io/etcd/blob/main/CHANGELOG/CHANGELOG-3.5.md#v3514-tbd

List of pull requests we still need to backport from main to release-3.5 before the patch release is issued:

• config: support AllowedCN and AllowedHostname through config file #17861

Why is this needed?

Regular patch releases are vital to ensure our users have bug free and secure software.

[serathius]

Using links like v3.5.13...release-3.5 is nice, but please note that they are not static, they update as the branch is moved. In previous releases I listed each issues explicitly to make sure that we have concrete list that can inspected after the release.

[jmhbnz]

Using links like v3.5.13...release-3.5 is nice, but please note that they are not static, they update as the branch is moved. In previous releases I listed each issues explicitly to make sure that we have concrete list that can inspected after the release.

Thanks yeah they are mutable until tag is published, once tag is published we can compare actual immutable list of commits, i.e. v3.5.12...v3.5.13

I have link to draft changelog and also the header for proposed issues still needing backport which I will add to shortly:

Work in progress CHANGELOG is: https://github.com/etcd-io/etcd/blob/main/CHANGELOG/CHANGELOG-3.5.md#v3514-tbd

List of items we still need to backport from main to release-3.5 before the patch release is issued:
TBC

[jmhbnz]

Updated planning for this release below:

---

Release team

Github handle	Role
@serathius	Release advisor
@jmhbnz	Release lead
@ivanvc	Release shadow

---

Backports

I have identified one required backport this morning and added to the list above. @ivanvc will also review and suggest any. @serathius are there any recent robustness related merges to main you would suggest we backport for 3.5.14?

Required backports will be discussed at triage tomorrow so we can invite the community to help get these completed in advance of the release date.

---

Release date

Discussed with @ivanvc today. We are both available 11:00 Pacific Time next Tuesday 28th or Wednesday 29th. @serathius would one of those options work for you for the call to cut the release? If so I will send the calendar invite.

[ivanvc]

I did a sweep of issues and pull requests from the main branch since v3.5.13, and couldn't find any other possible candidates for being backported.

[ivanvc]

@jmhbnz, @serathius, have we agreed on a date for the release?

[serathius]

Please reach out to me on Slack to setup the meeting.

[jmhbnz]

etcd v3.5.14 is now public https://github.com/etcd-io/etcd/releases/tag/v3.5.14

Thanks to everyone who contributed to the release.

I will leave this issue open for now as there are two release process improvement we would like to pursue following this release:

1. Consider switching to a shallow git clone in scripts/release.sh by appending --depth=1 to save time.
2. Explore if the gsutil command to set public ACL can be run on a subdirectory rather than entire bucket to prevent error message spam at conclusion of scripts/release.sh.

[ivanvc]

Consider switching to a shallow git clone in scripts/release.sh by appending --depth=1 to save time.

I'm currently testing this.

[ivanvc]

Consider switching to a shallow git clone in scripts/release.sh by appending --depth=1 to save time.

I'm currently testing this.

I tried with --single-branch, but because a shallow clone works fine (--depth=1), single branch is not required. Also per git's documentation:

--depth <depth>
      Create a shallow clone with a history truncated to the specified number of commits. Implies --single-branch unless --no-single-branch is given to fetch the histories near the tips of all branches.

[ivanvc]

2. Explore if the gsutil command to set public ACL can be run on a subdirectory rather than entire bucket to prevent error message spam at conclusion of scripts/release.sh.

I don't have a way to test this. So, I don't want to raise the PR. But, from the documentation it seems like it should be possible to pass a path.

Refer to: https://cloud.google.com/storage/docs/gsutil/commands/acl#set-options

The "set" sub-command has the following options

-R, -r

    Performs "acl set" request recursively, to all objects under the specified URL.

And https://cloud.google.com/storage/docs/gsutil/commands/acl#ch-examples

Grant the user john.doe@example.com READ access to all objects in example-bucket that begin with folder/:

gsutil acl ch -r -u john.doe@example.com:R gs://example-bucket/folder/

[jmhbnz]

So there are two instances where gsutil is being used in scripts/release.sh to set bucket ACL's:

etcd/scripts/release.sh

Line 246 in bf51a53

maybe_run gsutil -m acl ch -u allUsers:R -r "gs://etcd/${RELEASE_VERSION}/"

The above reference is ok as this is already limited to the specific etcd version being uploaded.

etcd/scripts/release.sh

Line 285 in bf51a53

maybe_run gsutil -m acl ch -u allUsers:R -r gs://artifacts.etcd-development.appspot.com

This is the one causing log spam, as there are just over 3,000 objects in the bucket and the command is targeting the entire bucket recursively.

This gs://artifacts.etcd-development.appspot.com bucket relates to the current etcd container image hosting we have in gcr. Based on this post I believe the only way we can avoid this log spam would be to have ACL's set at the bucket level marking the entire bucket as public.

Doing some more checking, one interesting thing is that the entire bucket seems to be already marked as fully public:

I confirmed this with gsutil by verifying the allUsers member was present at the bucket level:

 james  ~  
 ➜ gsutil iam get gs://artifacts.etcd-development.appspot.com --format=json \
   | jq '.bindings[].members[]' | grep allUsers
"allUsers"

Based on my findings above I believe there is no point running this command every release and we can just remove that problematic line from the release script without consequence. Or at very least gate it behind a check for allUsers as mentioned above, so the line only runs if for some reason the bucket wasn't already public.

We would need consensus from @ahrtr and @serathius on this.

[ahrtr]

Thanks for driving the improvement!

Based on my findings above I believe there is no point running this command every release and we can just remove that problematic line from the release script without consequence.

Sounds good, but please manually verify it. e.g.

• Manually push an image gcr.io/etcd-development/etcd:v3.5.99
• Remove your local image;
• try to pull it;
• finally remove it.

Also what if we transition from gcr.io to Artifact Registry?