add aws lambda function to send patch cherry pick notification

[cpanato]

What type of PR is this?

/kind feature

What this PR does / why we need it:

• add aws lambda function to send patch cherry pick notification

We will apply the terraform manually by logging in the aws account we have for sig-release. maybe in the future we can automation with github actions and OIDC federation.

It is in a mock by default to we test the email sending, and then we will need to open a ticket with aws to move the aws ses config to prod then we can send emails to the [email protected] (i will do that as a follow up)

sample email that will be sent by the automation (note this is valid for the next cycle.

Hello Kubernetes Community!

The cherry-pick deadline for the 1.30 branches is 2024-06-07 EOD PT.

The cherry-pick deadline for the 1.29 branches is 2024-06-07 EOD PT.

The cherry-pick deadline for the 1.28 branches is 2024-06-07 EOD PT.

The cherry-pick deadline for the 1.27 branches is 2024-06-07 EOD PT.


Here are some quick links to search for cherry-pick PRs:

- release-1.30: https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+is%3Aopen+base%3Arelease-1.30+label%3Ado-not-merge%2Fcherry-pick-not-approved

- release-1.29: https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+is%3Aopen+base%3Arelease-1.29+label%3Ado-not-merge%2Fcherry-pick-not-approved

- release-1.28: https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+is%3Aopen+base%3Arelease-1.28+label%3Ado-not-merge%2Fcherry-pick-not-approved

- release-1.27: https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+is%3Aopen+base%3Arelease-1.27+label%3Ado-not-merge%2Fcherry-pick-not-approved


For PRs that you intend to land for the upcoming patch sets, please ensure they have:

- a release note in the PR description

- /sig

- /kind

- /priority

- /lgtm

- /approve

- passing tests


Details on the cherry-pick process can be found here:

https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md

We keep general info and up-to-date timelines for patch releases here:

https://kubernetes.io/releases/patch-releases/#upcoming-monthly-releases

If you have any questions for the Release Managers, please feel free to reach out to us at #release-management (Kubernetes Slack) or [[email protected]](mailto:[email protected])


We wish everyone a happy and safe week!

SIG-Release Team

/assign @saschagrunert @xmudrii @puerco
cc @kubernetes/release-managers

Which issue(s) this PR fixes:

Fixes #2174

Special notes for your reviewer:

Does this PR introduce a user-facing change?

add aws lambda function to send patch cherry pick notification

[cpanato]

/assign @saschagrunert @xmudrii @puerco

[cpanato]

/hold

[xmudrii]

Putting my SIG K8s Infra contributor hat on

The AWS account that we are using is part of the Kubernetes AWS organization (or at least it should be) which is managed by SIG K8s Infra. At the moment, SIG K8s Infra don't have very strict rules about how accounts under the organization should be managed, but there are some (more or less stronger) recommendations.

Speaking of the infrastructure part, it's recommended that everything related to the infrastructure, especially to the long-term infrastructure, lives in kubernetes/k8s.io repo, even if it's managed by other SIGs. That's because of multiple reasons:

• This ensures that SIG K8s Infra has an idea what's running in each account, which is very helpful for eventual auditing and technical support
• SIG Release can use the infrastructure built by SIG K8s Infra to securely manage the infrastructure. For example, SIG K8s Infra is working on a new CI/CD pipeline for Terraform that would make it much easier to apply changes, and it's likely that such a pipeline will only work in k/k8s.io

This might be kind of a new thing for SIG K8s Infra too (as in SIGs maintaining their own infrastructure and Terraform configs), so I'm going to cc some of infra folks if they have any stronger opinions: @upodroid @BenTheElder @dims

Putting my SIG Release contributor hat on

I'm a little bit more towards the infrastructure code living in k/k8s.io for the sake of having all the configs in the single place. For the reference, all the infrastructure code related to pkgs.k8s.io is already living in k/k8s.io and is pretty much completely managed and maintained by us. If we have different pieces of the infrastructure in different places, there's a more significant risk that some parts of the infrastructure gets a little bit neglected.

[cpanato]

thanks, i will split it

[dims]

it's recommended that everything related to the infrastructure, especially to the long-term infrastructure, lives in kubernetes/k8s.io repo, even if it's managed by other SIGs

+100

[cpanato]

@xmudrii @dims terraform code moved to k8s.io: kubernetes/k8s.io#6853

[xmudrii]

Amazing job @cpanato, thank you for taking care of this!! I left mainly some nits, other than that, this looks great!

[BenTheElder]

+1 to #3627 (comment)

Yeah, k8s.io is a clearing house for "how did/do we setup this infra?", the implementation sources for components shouldn't live there but the cloud / infra configuration does and we have strongly delegated ownership to sub-accounts, directories, etc. We hope to have more automation and self service over time and we'll need to be careful to secure it so we want to avoid sprawl.

Thanks for splitting this.

Also: Thanks for taking a moment to automate away toil and keep the community better informed about deadlines ❤️

[xmudrii]

Some final nits

[xmudrii]

What I thought is that we often use some queries to search for PRs to merge, such as https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+is%3Aopen+label%3Algtm+label%3Aapproved+milestone%3Av1.30+label%3Ado-not-merge%2Fcherry-pick-not-approved+-label%3Ado-not-merge%2Fhold+-label%3Ado-not-merge%2Fneeds-kind+-label%3Ado-not-merge%2Frelease-note-label-needed

The URL is a bit longer, but I was thinking if we should put it in the message somewhere. It could be very helpful because folks could use it check if their PR satisfies the criteria, i.e. if their PR will be reviewed. We often have some case where folks think that they did everything, but they actually missed something, and the PR gets missed -- this might help to avoid such cases.

However, this is something we can follow up on, I wouldn't block this PR on this.

[xmudrii]

🎉
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cpanato, xmudrii

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cpanato,xmudrii]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[xmudrii]

@cpanato I'll leave it up to you to remove the hold when ready :)

[cpanato]

/unhold

[k8s-ci-robot]

PR needs rebase.

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-sigs/prow repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale