Sig-release: Announcement of 1.17.6 was wrong with wrong SHAs

[cpanato]

What happened:

The announcement posted for release 1.17.6 see the email was send with the wrong SHAs which mismatch the SHAs we can find in the GitHub release

The issue was identified and post here: https://github.com/kubernetes/sig-release/issues/1093#issuecomment-631663608

What you expected to happen:

the announcement email contains the correct SHAs to match the ones we can find in the GitHub release.

How to reproduce it (as minimally and precisely as possible):

N/A

Anything else we need to know?:

N/A

Environment:

N/A

/priority critical-urgent

[cpanato]

After an investigation, figured out the issue:

• Instead of copy the announce from the gs://kubernetes-release/archive/anago-v1.17.6/announcement.html I copied by mistake from gs://kubernetes-release-gcb/archive/anago-v1.17.6/announcement.html and that generate a mismatch in the SHA

the SHA for kubernetes.tar.gz in the wrong announcement is 5cd8f0e0bb3806f975c9209657463d87f01f014c783818a3d790d5c779cd02495719f1524dadeb6f4cdd5373fe695b4e5d7c63a51e0a0ed4c06de2350a8707a7

and the SHA in the correct one is 90b10c16aea412c39ea57f6ebb0f5cb74f939089ebad91cdc1a3c2d83890a88305b2e10e9cee4563258c718383be66ee9e90f06c6b07b8d6eb2d11a473ffd670

Action Items

• For the next release, double-check the location before getting the announcement
• Validate the content of the announcement and check if the SHA matches the ones in GitHub as well

Apologies if that causes any problem.

[hasheddan]

@cpanato this seems like a very easy mistake to make and something we should help alleviate with tooling :) I know I personally do not use the release-notify tool and generally copy paste from the links as you do. I think the fix here is to make the notification tool a better experience such that folks running releases don't opt for copy / pasting instead of using it :+1:

[justaugustus]

Agreed that there's something to be desired in the current workflow.
I think different results are produced for release-notify if you use the --nomock flag.

Echoing @hasheddan, mistakes happen, so don't beat yourself up!
The concern here was the potential that the artifacts has had been tampered with, so I'm glad that's cleared up.

@cpanato -- Please send a follow-up email to the 1.17 announce email, linking this issue. Once that's done, you can close this out.

@kubernetes/release-engineering -- let's turn our attention to reviewing @saschagrunert's PR for krel announce, which should provide a better experience in the future: https://github.com/kubernetes/release/pull/1173

[cpanato]

email sent out
/close

[k8s-ci-robot]

@cpanato: Closing this issue.

In response to this:

email sent out
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jwatte]

Does the kubernetes-release-gcb root really need to have a name that's so close to kubernetes-release?
"Next time I will try better" is not an actionable outcome, compared to making the mistake less likely to happen.

[justaugustus]

@jwatte -- I'm not sure that your feedback is especially helpful in a situation where someone made a mistake.

Here's what I've observed:

• A problem was reported
• The team responsible acknowledged the problem on a public mailing list and filed this issue to track
• We determined that the wrong announcement template was used to send the email
• A correction to the initial announcement was issued to the public mailing list
• We suggested a course of action and better UX --> https://github.com/kubernetes/sig-release/issues/1095#issuecomment-632056780

I would be curious to hear more about what you consider a more "actionable outcome".

w.r.t. GCS bucket names:

When you create a bucket, you permanently define its name, its geographic location, and the project it is part of.

ref: https://cloud.google.com/storage/docs/moving-buckets

We have limited control over the Google-owned GCS buckets that we currently use staging/releasing Kubernetes.

If you're interested in tracking the massive multi-team, multi-cycle work to move the release process to community-owned infra, you can subscribe to this issue: https://github.com/kubernetes/release/issues/911