Plan to release etcd v3.5.14 about etcd HOT 12 OPEN

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.

from etcd.

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

I'm currently testing this.

from etcd.

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.

from etcd.

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.

from etcd.

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

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

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.

from etcd.

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.

from etcd.

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

from etcd.

Updated planning for this release below:

Release team

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.

from etcd.

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

from etcd.

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

from etcd.

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 [email protected] READ access to all objects in example-bucket that begin with folder/:

gsutil acl ch -r -u [email protected]:R gs://example-bucket/folder/

from etcd.

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?

from etcd.