Merge branch 'kubernetes:master' into fix-corp-cla-info-6584

14 files changed, 329 insertions, 153 deletions

diff --git a/communication/slack-config/channels.yaml b/communication/slack-config/channels.yaml
index 4293795c..bfe0c43e 100644
--- a/communication/slack-config/channels.yaml
+++ b/communication/slack-config/channels.yaml
@@ -472,3 +472,5 @@ channels:
   - name: windows-containerd
   - name: workshop-chat
   - name: yaml-overlay-tool
+  - name: zarf
+  - name: zarf-dev
diff --git a/contributors/devel/running-locally.md b/contributors/devel/running-locally.md
index effdde32..3c2d9563 100644
--- a/contributors/devel/running-locally.md
+++ b/contributors/devel/running-locally.md
@@ -156,7 +156,7 @@ change the service-cluster-ip-range flag to something else.
 
 ### I cannot create a replication controller with replica size greater than 1!  What gives?
 
-You are running a single node setup.  This has the limitation of only supporting a single replica of a given pod.  If you are interested in running with larger replica sizes, we encourage you to try the local vagrant setup or one of the cloud providers.
+You are running a single node setup.  This has the limitation of only supporting a single replica of a given pod.  If you are interested in running with larger replica sizes, we encourage you to try Kind or one of the cloud providers.
 
 ### I changed Kubernetes code, how do I run it?
 
diff --git a/contributors/devel/sig-instrumentation/migration-to-structured-logging.md b/contributors/devel/sig-instrumentation/migration-to-structured-logging.md
index cbe5c6d7..2922300d 100644
--- a/contributors/devel/sig-instrumentation/migration-to-structured-logging.md
+++ b/contributors/devel/sig-instrumentation/migration-to-structured-logging.md
@@ -1,17 +1,20 @@
-# Structured Logging migration instructions
+# Structured and Contextual Logging migration instructions
 
-This document describes instructions for migration proposed by [Structured Logging KEP]. It describes new structured
+This document describes instructions for the migration proposed by [Structured Logging KEP] and [Contextual Logging KEP]. It describes new
 functions introduced in `klog` (Kubernetes logging library) and how log calls should be changed to utilize new features.
-This document was written for the initial migration of `kubernetes/kubernetes` repository proposed for Alpha stage, but
+This document was written for the initial migration of `kubernetes/kubernetes` repository proposed for Alpha stage of structured logging, but
 should be applicable at later stages or for other projects using `klog` logging library.
 
 [Structured Logging KEP]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging
+[Contextual Logging KEP]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging
 
 ## How to contribute
 
 ### About the migration
 
-We would like for the Kubernetes community to settle on one preferred log message structure, that will be enforced by new klog methods. The goal of the migration is to switch C like format string logs to structured logs with explicit metadata about parameters.
+We would like for the Kubernetes community to settle on one preferred log message structure and log calls as defined by [logr].
+The goal of the migration is to switch C-like format string logs to structured logs with explicit metadata about parameters and
+to remove the global logger in klog with a `logr.Logger` instance that gets chosen by the caller of a function.
 
 Migration within the structured logging working group happens in two different ways - organized & non-organized. 
 
@@ -42,6 +45,7 @@ Before sending a PR our way, please ensure that there isn't one already in place
 * 1.21 Kubelet was migrated
 * 1.22 Collected feedback and improved the process.
 * 1.23 kube-scheduler and kube-proxy were migrated.
+* 1.24 Contextual logging infrastructure (updated klog, component-base/logs enables it) in place.
 
 ## Sending a Structured Logging Migration Pull Request
 
@@ -78,7 +82,7 @@ Migrate <directory/file> to structured logging
 
 ### Why my PR was rejected?
 
-Even though the Kubernetes project is organizing migration of Structured Logging, this doesn't mean that we are able to accept all the PRs that come our way. We reserve the right to reject the Pull Request in situations listed below:
+Even though the Kubernetes project is organizing migration of logging, this doesn't mean that we are able to accept all the PRs that come our way. We reserve the right to reject the Pull Request in situations listed below:
 
 * Pull request is below minimum quality standards and clearly shows that author hasn't read the guide at all, for example PR just renames `Infof` to `InfoS`.
 * Pull request migrates components that the owners have decided against migrating. List of those components:
@@ -168,20 +172,86 @@ type KMetadata interface {
 }
 ```
 
+## Contextual logging in Kubernetes
+
+Contextual logging builds on top of structured logging because the parameters
+for individual log calls are the same. The difference is that different
+functions need to be used:
+
+- `klog.ErrorS` -> `logger.Error`
+- `klog.InfoS` -> `logger.Info`
+- `klog.V().InfoS` -> `logger.V().Info`
+
+In all of these cases, `logger` is a `logr.Logger` instance. `klog.Logger` is
+an alias for that type. Determining where that instance comes from is the main
+challenge when migrating code to contextual logging.
+
+Several new klog functions help with that:
+
+- [`klog.FromContext`](https://pkg.go.dev/k8s.io/klog/v2#FromContext)
+- [`klog.Background`](https://pkg.go.dev/k8s.io/klog/v2#Background)
+- [`klog.TODO`](https://pkg.go.dev/k8s.io/klog/v2#TODO)
+
+The preferred approach is to retrieve the instance with `klog.FromContext` from
+a `ctx context` parameter. If a function or method does not have one, consider
+adding it. This API change then implies that all callers also need to be
+updated. If there are any `context.TODO` calls in the modified functions,
+replace with the new `ctx` parameter.
+
+In performance critical code it may be faster to add a `logger klog.Logger`
+parameter. This needs to be decided on a case-by-case basis.
+
+When such API changes trickle up to a unit test, then enable contextual logging
+with per-test output with
+[`ktesting`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting):
+
+```go
+import (
+    "testing"
+
+    "k8s.io/klog/v2/ktesting"
+    _ "k8s.io/klog/v2/ktesting/init" # Add command line flags for ktesting.
+)
+
+func TestFoo(t *testing.T) {
+   _, ctx := ktesting.NewTestContext(t)
+   doSomething(ctx)
+}
+```
+
+If a logger instance is needed instead, then use:
+
+```go
+   logger, _ := ktesting.NewTestContext(t)
+```
+
+The KEP has further instructions about the [transition to contextual
+logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging#transition). It
+also lists several
+[pitfalls](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging#pitfalls-during-usage)
+that developers and reviewers need to be aware of.
+
 ## Migration
 
-1. Change log functions to structured equivalent
+1. Optional: find code locations that need to be changed:
+
+   - `(cd hack/tools && go install k8s.io/klog/hack/tools/logcheck)`
+   - structured logging: `$GOPATH/bin/logcheck -check-structured ./pkg/controller/...`
+   - contextual logging: `$GOPATH/bin/logcheck -check-contextual ./pkg/scheduler/...`
+
+1. Change log functions to structured or (better!) contextual equivalent
 1. Remove string formatting from log message
 1. Name arguments
 1. Ensure that value is properly passed
 1. Verify log output
+1. Prevent re-adding banned functions after migration
 
-## Change log functions to structured equivalent
+## Change log functions
 
 Structured logging functions follow a different logging interface design than other functions in `klog`. They follow
 minimal design from [logr] thus there is no one-to-one mapping.
 
-Simplified mapping between functions:
+Simplified mapping between functions for structured logging:
 * `klog.Infof`, `klog.Info`, `klog.Infoln` -> `klog.InfoS`
 * `klog.InfoDepth` -> `klog.InfoSDepth`
 * `klog.V(N).Infof`, `klog.V(N).Info`, `klog.V(N).Infoln` -> `klog.V(N).InfoS`
@@ -189,26 +259,42 @@ Simplified mapping between functions:
 * `klog.WarningDepth` -> `klog.InfoSDepth`
 * `klog.Error`, `klog.Errorf`, `klog.Errorln` -> `klog.ErrorS`
 * `klog.ErrorDepth` -> `klog.ErrorSDepth`
-* `klog.Fatal`, `klog.Fatalf`, `klog.Fatalln` -> `klog.ErrorS` followed by `os.Exit(1)` ([see below])
-* `klog.FatalDepth` -> `klog.ErrorDepth` followed by `os.Exit(1)` ([see below])
+* `klog.Fatal`, `klog.Fatalf`, `klog.Fatalln` -> `klog.ErrorS` followed by `klog.FlushAndExit(klog.ExitFlushTimeout, klog.1)` ([see below])
+* `klog.FatalDepth` -> `klog.ErrorDepth` followed by `klog.FlushAndExit(klog.ExitFlushTimeout, klog.1)` ([see below])
+
+For contextual logging, replace furthermore:
+
+- `klog.ErrorS` -> `logger.Error`
+- `klog.InfoS` -> `logger.Info`
+- `klog.V().InfoS` -> `logger.V().Info`
 
 [see below]: #replacing-fatal-calls
 
-### Using ErrorS
+### Using ErrorS or logger.Error
 
 With `klog` structured logging borrowing the interface from [logr] it also inherits it's differences in semantic of
 error function. Logs generated by `ErrorS` command may be enhanced with additional debug information
 (such as stack traces) or be additionally sent to special error recording tools. Errors should be used to indicate
 unexpected behaviours in code, like unexpected errors returned by subroutine function calls.
+In contrast to info log calls, error log calls always record the log entry, regardless of the current verbosity
+settings.
 
-Calling `ErrorS` with `nil` as error is semi-acceptable if there is error condition that deserves a stack trace at this
-origin point. For expected errors (`errors` that can happen during routine operations) please consider using
+Calling `ErrorS` with `nil` as error is acceptable if there is an error condition that deserves a stack trace at this
+origin point or always must be logged. For expected errors (`errors` that can happen during routine operations) please consider using
 `klog.InfoS` and pass error in `err` key instead.
 
 ### Replacing Fatal calls
 
 Use of Fatal should be discouraged and it's not available in new functions. Instead of depending on the logger to exit
-the process, you should call `os.Exit()` yourself.
+the process, you should:
+- rewrite code to return an `error` and let the caller deal with it or, if that is not feasible,
+- log and exit separately.
+
+`os.Exit` should be avoided because it skips log data flushing. Instead use
+[`klog.FlushAndExit`](https://pkg.go.dev/k8s.io/klog/v2#FlushAndExit). The first
+parameter determines how long the program is allowed to flush log data before
+`os.Exit` is called. If unsure, use `klog.ExitFlushTimeout`, the value used
+by `klog.Fatal`.
 
 Fatal calls use a default exit code of 255. When migrating, please use an exit code of 1 and include an "ACTION REQUIRED:" release note.
 
@@ -217,7 +303,6 @@ For example
 func validateFlags(cfg *config.Config, flags *pflag.FlagSet) error {
 	if err := cfg.ReadAndValidate(flags); err != nil {
 		klog.FatalF("Error in reading and validating flags %s", err)
-      os.Exit(1)
 	}
 }
 ```
@@ -226,7 +311,7 @@ should be changed to
 func validateFlags(cfg *config.Config, flags *pflag.FlagSet) error {
 	if err := cfg.ReadAndValidate(flags); err != nil {
 		klog.ErrorS(err, "Error in reading and validating flags")
-      os.Exit(1)
+		klog.FlushAndExit(klog.ExitFlushTimeout, 1)
 	}
 }
 ```
@@ -526,3 +611,27 @@ After
 ```
 I0528 19:15:22.737588   47512 logtest.go:55] "Received HTTP request" verb="GET" URI="/metrics" latency="1s" resp=200 userAgent="Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0. 2272.118 Safari/537.36." srcIP="127.0.0.1"
 ```
+
+## Prevent re-adding banned functions after migration
+
+After a package has been migrated to structured and/or contextual logging, we
+want to ensure that all log calls that get added in future PRs are structured
+resp. contextual.
+
+For structured logging, the list of migrated packages in
+[`hack/logcheck.conf`](https://github.com/kubernetes/kubernetes/blob/b9792a9daef4d978c5c30b6d10cbcdfa77a9b6ac/hack/logcheck.conf#L16-L22)
+can be extended.
+
+For contextual logging, a new list can be added at the bottom once the code is
+ready, with content like this:
+
+```
+# Packages that have been migrated to contextual logging:
+contextual k8s.io/kubernetes/pkg/scheduler/.*
+```
+
+The corresponding line with `structured k8s.io/kubernetes/pkg/scheduler/.*`
+then is redundant and can be removed because "contextual" implies "structured".
+
+Both lists should be sorted alphabetically. That reduces the risk of code
+conflicts and makes the file more readable.
diff --git a/contributors/guide/issue-triage.md b/contributors/guide/issue-triage.md
index 472ff4b2..6c01a4d6 100644
--- a/contributors/guide/issue-triage.md
+++ b/contributors/guide/issue-triage.md
@@ -154,8 +154,7 @@ Note that adding labels requires Kubernetes GitHub org membership. If you are no
 
 GitHub allows you to filter out types of issues and pull requests, which helps you discover items in need of triaging. This table includes some predetermined searches for convenience:
 
-<!--- NOTE: Table syntax is for the Hugo rendered page -->
-{{< table caption="Example issue and pull request searches" >}}
+
 | Search                                                                                                       | What it sorts                                           |
 |--------------------------------------------------------------------------------------------------------------|---------------------------------------------------------|
 | [created-asc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc)     | Untriaged issues by age                                 |
@@ -163,7 +162,7 @@ GitHub allows you to filter out types of issues and pull requests, which helps y
 | [`is:open is:issue`](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue)                 | Newest incoming issues                                  |
 | [comments-desc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc) | Busiest untriaged issues, sorted by # of comments       |
 | [comments-asc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc)   | Issues that need more attention, based on # of comments |
-{{</ table >}}
+
 
 We suggest preparing your triage by filtering out the oldest, unlabelled issues and pull requests first.
 
@@ -223,8 +222,7 @@ We use GitHub labels for prioritization. If an issue lacks a `priority` label, t
 
 We aim for consistency across the entire project. However, if you notice an issue that you believe to be incorrectly prioritized, please leave a comment offering your counter-proposal and we will evaluate it.
 
-<!--- NOTE: Table syntax is for the Hugo rendered page -->
-{{< table caption="Priority labels for issues" >}}
+
 |Priority label|What it means|Examples|
 |---|---|---|
 | `priority/critical-urgent` | Team leaders are responsible for making sure that these issues (in their area) are being actively worked on—i.e., drop what you're doing. Stuff is burning. These should be fixed before the next release. | user-visible bugs in core features <br> broken builds <br> tests and critical security issues | 
@@ -232,7 +230,7 @@ We aim for consistency across the entire project. However, if you notice an issu
 | `priority/important-longterm` | Important over the long term, but may not be currently staffed and/or may require multiple releases to complete. Wouldn't block a release. | [**XXXX**]|
 | `priority/backlog`  | General agreement that this is a nice-to-have, but no one's available to work on it anytime soon. Community contributions would be most welcome in the meantime, though it might take a while to get them reviewed if reviewers are fully occupied with higher-priority issues—for example, immediately before a release.| [**XXXX**]  | 
 | `priority/awaiting-more-evidence` | Possibly useful, but not yet enough support to actually get it done. | Mostly placeholders for potentially good ideas, so that they don't get completely forgotten, and can be referenced or deduped every time they come up | 
-{{< /table >}}
+
 
 ## Step Four: Find and Set the Right SIG(s) to Own an Issue 
 
diff --git a/mentoring/programs/mentoring-lead.md b/mentoring/programs/mentoring-lead.md
new file mode 100644
index 00000000..a536763c
--- /dev/null
+++ b/mentoring/programs/mentoring-lead.md
@@ -0,0 +1,58 @@
+# Internship Mentoring Lead Handbook
+
+## Overview
+
+The Mentoring Lead role is created to help upstream Kubernetes contributors to participates in various mentorship programs like [GSoC](https://github.com/kubernetes/community/blob/master/mentoring/programs/google-summer-of-code.md), [GSoD](https://github.com/kubernetes/community/blob/master/mentoring/programs/google-season-of-docs.md), [LFX Mentorship](https://github.com/kubernetes/community/blob/master/mentoring/programs/lfx-mentorship.md) and many more as an independent organisation or under Cloud Native Computing Foundation(CNCF). 
+
+## Responsibilities
+ The role lead should:
+
+- Keep a calendar of dates for each program (when to submit our project name, when to submit the project scope, when selecting period is, etc) throughout the   year and
+- Coordinate all submissions and participation in each one
+- Go to sig meetings and slack channels to proactively help with scoping and planning work / job descriptions
+- Help onboard interns to the k8s specific community items like coordinate a hello for them at the k8s monthly community meeting
+- Help off board interns to the k8s specific community items like demo at monthly community meeting
+
+
+### Role Description
+
+Major responsibilities includes a commitment to: 
+
+- Be proactive in information sharing, through the mailing list/slack channels, regarding various mentorship cohorts
+- Be a bridge between the CNCF staff, mentors, and mentees from kubernetes project
+- Be an active contributor, who could identify parts of the project that could get help from mentorship programs
+- Be a go-to person for all SIGs to help them with their mentorship proposals
+- Be welcoming of everyone by being your unique self
+- Be inclusive on contributors, especially with new contributors joining kubernetes project as part of the mentoring process
+- Be a leader of the mentoring sub-project with a commitment to its charter
+
+### Minimum Skills and Requirements
+
+Skills:
+
+- Be comfortable with general GitHub workflows. You'll be working inside of multiple repositories with different workflows and helping others on the team with troubleshooting.
+- Be a team player, making the project welcoming for new mentees and helping other members of the project interested to part in mentorship with the process.
+- Be willing and capable of saying "no" as necessary, but try to get to a "yes, and" to help the community achieve its goals. In short, be empathetic.
+- Strong written and verbal communication skills. A willingness to meet (a lot) of new people is important for this work.
+
+Requirements:
+
+- Member of the [Kubernetes GitHub Org]
+- [Reviewer] in the mentoring folder
+- Not Necessary, but a previous mentee/mentor in any of the mentorship programme is preferrable
+
+#### Expected Time Investment
+
+- Four hours a week as a minimal target, might be two hours more during the proposal submission perios
+
+#### Duration  
+
+Ideally, no lead should be in the same position indefinitely. With that in mind,the project would like to see new leadership every 24 months to keep a fresh perspective. 
+
+### Becoming a Shadow
+
+Any regular contributor to mentoring subproject can put forward their interest to the mentoring lead to become a shadow. If accepted, the objective of the council members is to nurture that shadow into a leadership position in the next 12 months. 
+
+#### Expectations of a Shadow
+
+Consistently communicate and collaborate closely with the lead. The objective is to get you, as the shadown, to be a confident leader of the above responsibilities. Be ready to backfill for them when they are unable to attend a meeting or represent the subproject.
\ No newline at end of file
diff --git a/sig-cloud-provider/README.md b/sig-cloud-provider/README.md
index d7c54ce5..6f3c6d13 100644
--- a/sig-cloud-provider/README.md
+++ b/sig-cloud-provider/README.md
@@ -123,7 +123,7 @@ The following [subprojects][subproject-definition] are owned by sig-cloud-provid
   - [kubernetes-sigs/ibm-powervs-block-csi-driver](https://github.com/kubernetes-sigs/ibm-powervs-block-csi-driver/blob/main/OWNERS)
   - [kubernetes-sigs/ibm-vpc-block-csi-driver](https://github.com/kubernetes-sigs/ibm-vpc-block-csi-driver/blob/master/OWNERS)
 - **Meetings:**
-  - Regular IBM Subproject Meeting: [Wednesdays at 14:00 EST](https://zoom.us/j/9392903494) (biweekly). [Convert to your timezone](http://www.thetimezoneconverter.com/?t=14:00&tz=EST).
+  - Regular IBM Subproject Meeting: [Wednesdays at 14:00 ET (Eastern Time)](https://zoom.us/j/9392903494) (monthly - last Wednesday every month). [Convert to your timezone](http://www.thetimezoneconverter.com/?t=14:00&tz=ET%20%28Eastern%20Time%29).
     - [Meeting notes and Agenda](https://docs.google.com/document/d/1qd_LTu5GFaxUhSWTHigowHt3XwjJVf1L57kupj8lnwg/edit).
 ### provider-openstack
 - **Owners:**
diff --git a/sig-list.md b/sig-list.md
index d9bf73e2..3f6e292f 100644
--- a/sig-list.md
+++ b/sig-list.md
@@ -38,7 +38,7 @@ When the need arises, a [new SIG can be created](sig-wg-lifecycle.md)
 |[Auth](sig-auth/README.md)|[auth](https://github.com/kubernetes/kubernetes/labels/sig%2Fauth)|* [Mo Khan](https://github.com/enj), VMware<br>* [Mike Danese](https://github.com/mikedanese), Google<br>* [Rita Zhang](https://github.com/ritazh), Microsoft<br>|* [Slack](https://kubernetes.slack.com/messages/sig-auth)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-auth)|* Regular SIG Meeting: [Wednesdays at 11:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/264572674)<br>* Secrets Store CSI Meeting: [Thursdays at 8:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/91272289538)<br>
 |[Autoscaling](sig-autoscaling/README.md)|[autoscaling](https://github.com/kubernetes/kubernetes/labels/sig%2Fautoscaling)|* [Guy Templeton](https://github.com/gjtempleton), Skyscanner<br>* [Marcin Wielgus](https://github.com/mwielgus), Google<br>|* [Slack](https://kubernetes.slack.com/messages/sig-autoscaling)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-autoscaling)|* Regular SIG Meeting: [Mondays at 16:00 Poland (weekly)](https://zoom.us/j/944410904)<br>
 |[CLI](sig-cli/README.md)|[cli](https://github.com/kubernetes/kubernetes/labels/sig%2Fcli)|* [Katrina Verey](https://github.com/KnVerey), Shopify<br>* [Eddie Zaneski](https://github.com/eddiezane), Chainguard, Inc<br>* [Sean Sullivan](https://github.com/seans3), Google<br>|* [Slack](https://kubernetes.slack.com/messages/sig-cli)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-cli)|* Bug Scrub: [Wednesdays at 09:00 PT (Pacific Time) (monthly)](https://zoom.us/j/288426795?pwd=UDdoYnFyNjBiS1RHcXRxS1BCNy9wUT09)<br>* KRM Functions Subproject Meeting: [Wednesdays at 10:30 PT (Pacific Time) (biweekly)](https://zoom.us/j/288426795?pwd=UDdoYnFyNjBiS1RHcXRxS1BCNy9wUT09)<br>* Kustomize Bug Scrub: [Wednesdays at 09:00 PT (Pacific Time) (monthly)](https://zoom.us/j/288426795?pwd=UDdoYnFyNjBiS1RHcXRxS1BCNy9wUT09)<br>* Regular SIG Meeting: [Wednesdays at 09:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/288426795?pwd=UDdoYnFyNjBiS1RHcXRxS1BCNy9wUT09)<br>
-|[Cloud Provider](sig-cloud-provider/README.md)|[cloud-provider](https://github.com/kubernetes/kubernetes/labels/sig%2Fcloud-provider)|* [Andrew Sy Kim](https://github.com/andrewsykim), Google<br>* [Walter Fender](https://github.com/cheftako), Google<br>* [Nick Turner](https://github.com/nckturner), Amazon<br>|* [Slack](https://kubernetes.slack.com/messages/sig-cloud-provider)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-cloud-provider)|* Regular SIG Meeting: [Wednesdays at 9:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/508079177?pwd=ZmEvMksxdTFTc0N1eXFLRm91QUlyUT09)<br>* (cloud-provider-extraction-migration) Weekly Sync removing the in-tree cloud providers led by @cheftako and @mcrute: [Thursdays at 13:30 PT (Pacific Time) (weekly)](https://docs.google.com/document/d/1KLsGGzNXQbsPeELCeF_q-f0h0CEGSe20xiwvcR2NlYM/edit)<br>* (provider-alibaba-cloud) Regular Alibaba Cloud Subproject Meeting: [Tuesdays at 12:00 UTC (monthly 2020 start date: Jan. 7th)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>* (provider-aws) Regular AWS Subproject Meeting: [Fridays at 9:00 PT (Pacific Time) (biweekly 2019 start date: Jan. 11th)](https://zoom.us/my/k8ssigaws)<br>* (provider-azure) Azure Subproject Meeting: [Mondays at 18:00 PT (Pacific Time) (monthly - third Monday)](https://zoom.us/j/586836662)<br>* (provider-gcp) Regular GCP Subproject Meeting: [Thursdays at 16:00 UTC (biweekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>* (provider-ibmcloud) Regular IBM Subproject Meeting: [Wednesdays at 14:00 EST (biweekly)](https://zoom.us/j/9392903494)<br>* (provider-openstack) Regular OpenStack Subproject Meeting: [Wednesdays at 08:00 PT (Pacific Time) (biweekly starting Wednesday March 20, 2019)](https://docs.google.com/document/d/1bW3j4hFN4D8rv2LFv-DybB3gcE5ISAaOO_OpvDCgrGg/edit)<br>* (provider-vsphere) Cloud Provider vSphere monthly syncup: [Wednesdays at 09:00 PT (Pacific Time) (monthly - first Wednesday every month)](https://zoom.us/j/584244729)<br>
+|[Cloud Provider](sig-cloud-provider/README.md)|[cloud-provider](https://github.com/kubernetes/kubernetes/labels/sig%2Fcloud-provider)|* [Andrew Sy Kim](https://github.com/andrewsykim), Google<br>* [Walter Fender](https://github.com/cheftako), Google<br>* [Nick Turner](https://github.com/nckturner), Amazon<br>|* [Slack](https://kubernetes.slack.com/messages/sig-cloud-provider)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-cloud-provider)|* Regular SIG Meeting: [Wednesdays at 9:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/508079177?pwd=ZmEvMksxdTFTc0N1eXFLRm91QUlyUT09)<br>* (cloud-provider-extraction-migration) Weekly Sync removing the in-tree cloud providers led by @cheftako and @mcrute: [Thursdays at 13:30 PT (Pacific Time) (weekly)](https://docs.google.com/document/d/1KLsGGzNXQbsPeELCeF_q-f0h0CEGSe20xiwvcR2NlYM/edit)<br>* (provider-alibaba-cloud) Regular Alibaba Cloud Subproject Meeting: [Tuesdays at 12:00 UTC (monthly 2020 start date: Jan. 7th)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>* (provider-aws) Regular AWS Subproject Meeting: [Fridays at 9:00 PT (Pacific Time) (biweekly 2019 start date: Jan. 11th)](https://zoom.us/my/k8ssigaws)<br>* (provider-azure) Azure Subproject Meeting: [Mondays at 18:00 PT (Pacific Time) (monthly - third Monday)](https://zoom.us/j/586836662)<br>* (provider-gcp) Regular GCP Subproject Meeting: [Thursdays at 16:00 UTC (biweekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>* (provider-ibmcloud) Regular IBM Subproject Meeting: [Wednesdays at 14:00 ET (Eastern Time) (monthly - last Wednesday every month)](https://zoom.us/j/9392903494)<br>* (provider-openstack) Regular OpenStack Subproject Meeting: [Wednesdays at 08:00 PT (Pacific Time) (biweekly starting Wednesday March 20, 2019)](https://docs.google.com/document/d/1bW3j4hFN4D8rv2LFv-DybB3gcE5ISAaOO_OpvDCgrGg/edit)<br>* (provider-vsphere) Cloud Provider vSphere monthly syncup: [Wednesdays at 09:00 PT (Pacific Time) (monthly - first Wednesday every month)](https://zoom.us/j/584244729)<br>
 |[Cluster Lifecycle](sig-cluster-lifecycle/README.md)|[cluster-lifecycle](https://github.com/kubernetes/kubernetes/labels/sig%2Fcluster-lifecycle)|* [Justin Santa Barbara](https://github.com/justinsb), Google<br>* [Lubomir Ivanov](https://github.com/neolit123), VMware<br>* [Vince Prignano](https://github.com/vincepri), VMware<br>|* [Slack](https://kubernetes.slack.com/messages/sig-cluster-lifecycle)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)|* Regular SIG Meeting: [Tuesdays at 09:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/916523531?pwd=eVhPNU5IQWtBYWhmT1N4T0V6bHZFZz09)<br>* (cluster-addons) Cluster Addons meeting: [Tuesdays at 09:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/130096731?pwd=U3pzWloxZ0lpbEtadTZGSERRdENrZz09)<br>* (cluster-api) Cluster API office hours: [Wednesdays at 10:00 PT (Pacific Time) (weekly)](https://zoom.us/j/861487554?pwd=dTVGVVFCblFJc0VBbkFqQlU0dHpiUT09)<br>* (cluster-api-provider-aws) Cluster API Provider AWS office hours: [Mondays at 09:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/423312508?pwd=Tk9OWnZ4WHg2T2xRek9xZXA1eFQ4dz09)<br>* (cluster-api-provider-azure) Cluster API Provider Azure office hours: [Thursdays at 08:00 PT (Pacific Time) (bi-weekly)](https://zoom.us/j/566930821?pwd=N2JuRWljc3hGS3ZnVlBLTk42TFlzQT09)<br>* (cluster-api-provider-digitalocean) Cluster API Provider DigitalOcean office hours: [Thursdays at 09:00 PT (Pacific Time) (monthly, second Thursday of the month)](https://zoom.us/j/91312171751?pwd=bndnMDdJMkhySDVncjZoR1VhdFBTZz09)<br>* (cluster-api-provider-ibmcloud) Cluster API Provider IBM Cloud office hours: [Fridays at 09:00 IST (weekly)](https://zoom.us/j/9392903494)<br>* (cluster-api-provider-kubevirt) Cluster API Provider KubeVirt Syncup Meetings: [Tuesdays at 8:00 PT (Pacific Time) (weekly starting Tuesday December 7th, 2021)](https://zoom.us/j/94685513559?pwd=cnI3RUQyZ3RrckpOc1BQNDA1Q1BrZz09)<br>* (cluster-api-provider-nested) Cluster API Provider Nested Office Hours: [Tuesdays at 10:00 PT (Pacific Time) (weekly)](https://zoom.us/j/91929881559?pwd=WllxazhTUzBFN1BNWTRadTA3NGtQQT09)<br>* (cluster-api-provider-vsphere) Cluster API vSphere meeting: [Thursdays at 10:00 PT (Pacific Time) (biweekly starting Thursday June 25th, 2020)](https://zoom.us/j/92253194848?pwd=cVVVNDMxeTl1QVJPUlpvLzNSVU1JZz09)<br>* (etcdadm) etcdadm Office Hours: [Mondays at 09:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/612375927?pwd=MldxRnRSOExCVW1rbjM4ZzBSc3MvUT09)<br>* (image-builder) Image Builder office hours: [Thursdays at 08:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/807524571?pwd=WEFTeDJzeWU3bVFkcWQ0UEdZRkRCdz09)<br>* (kOps) kOps Office Hours: [Fridays at 09:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/97072789944?pwd=VVlUR3dhN2h5TEFQZHZTVVd4SnJUdz09)<br>* (kubeadm) kubeadm Office Hours: [Wednesdays at 09:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/179916854?pwd=dzRhbjFnRGVQRDVUVHY1a29JV2JxUT09)<br>* (minikube) minikube office hours: [Mondays at 11:00 PT (Pacific Time) (biweekly)](https://zoom.us/j/97017029363?pwd=U3MvZ3pMMHM5eWorSjgzUnd5OEFtUT09)<br>
 |[Contributor Experience](sig-contributor-experience/README.md)|[contributor-experience](https://github.com/kubernetes/kubernetes/labels/sig%2Fcontributor-experience)|* [Alison Dowdney](https://github.com/alisondy), Kasten<br>* [Bob Killen](https://github.com/mrbobbytables), Google<br>|* [Slack](https://kubernetes.slack.com/messages/sig-contribex)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-contribex)|* Regular SIG Meeting: [Wednesdays at 9:00 PT (Pacific Time) (weekly alternating slack/zoom)](https://zoom.us/j/397264241?pwd=bHNnZVArNFdPaWVJMmttdko0Sktudz09)<br>* (contributor-comms) Contributor Comms - Upstream Marketing Team Meeting: [Fridays at 8:00 PT (Pacific Time) (weekly)](https://zoom.us/j/596959769?pwd=TURBNlZPb3BEWVFmbWlCYXlMVVJiUT09)<br>* (events) Office Hours European Edition (Open Q&A for end-user kubernetes related questions): [Wednesdays at 09:00 ET (Eastern Time) (monthly on 3rd Wednesday)](https://hackmd.io/@k8s/office-hours)<br>* (events) Office Hours Western Edition (Open Q&A for end-user kubernetes related questions): [Wednesdays at 12:00 ET (Eastern Time) (monthly on 3rd Wednesday)]()<br>* (github-management) GitHub Administration Subproject: [Thursdays at 09:30 PT (Pacific Time) (Monthly on 4th Thursday)](https://zoom.us/j/442435463?pwd=Rk1PWWpSSTJDaWJKdzRYb2EyTlkvZz09)<br>
 |[Docs](sig-docs/README.md)|[docs](https://github.com/kubernetes/kubernetes/labels/sig%2Fdocs)|* [Divya Mohan](https://github.com/divya-mohan0209), SUSE<br>* [Jim Angel](https://github.com/jimangel), Google<br>* [Natali Vlatko](https://github.com/natalisucks), Wayfair<br>* [Rey Lejano](https://github.com/reylejano), SUSE<br>|* [Slack](https://kubernetes.slack.com/messages/sig-docs)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)|* APAC SIG Meeting: [Wednesdays at 05:30 UTC (monthly - Wednesday, after the fourth Tuesday, every month)](https://docs.google.com/document/d/1emuO4nmaQq3K8JZ9-MQeIygtrCPO9kWv7U7RzTaW4F8/edit)<br>* Korean Team Meeting: [Thursdays at 13:00 UTC (biweekly)](https://docs.google.com/document/d/1h5sMhBpPB5unJmBAS7KzDiPs-_eFQOu5o4UyHwMtFCA/edit)<br>* Localization Subgroup Meeting: [Mondays at 15:00 UTC (monthly)](https://docs.google.com/document/d/1NwO1AN8Ea2zlK8uAdaDAKf1-LZDAFvSewIfrKqfl5No/)<br>* Regular SIG Meeting: [Tuesdays at 17:30 UTC (weekly - except fourth Tuesday every month)](https://docs.google.com/document/d/1emuO4nmaQq3K8JZ9-MQeIygtrCPO9kWv7U7RzTaW4F8/edit)<br>* Spanish Team Meeting: [Tuesdays at 15:30 UTC (weekly)](https://zoom.us/j/95918289494?pwd=Wk9Oa0xZUkFXSDV5OTFoZEZsTURCZz09)<br>
diff --git a/sig-release/README.md b/sig-release/README.md
index 4aa4b715..d393ee41 100644
--- a/sig-release/README.md
+++ b/sig-release/README.md
@@ -31,7 +31,7 @@ The Technical Leads of the SIG establish new subprojects, decommission existing
 subprojects, and resolve cross-subproject technical issues and decisions.
 
 * Carlos Tadeu Panato Jr. (**[@cpanato](https://github.com/cpanato)**), Chainguard, Inc
-* Jeremy Rickard (**[@jeremyrickard](https://github.com/jeremyrickard)**), Apple
+* Jeremy Rickard (**[@jeremyrickard](https://github.com/jeremyrickard)**), Microsoft
 * Adolfo García Veytia (**[@puerco](https://github.com/puerco)**), Chainguard, Inc
 
 ## Emeritus Leads
@@ -100,6 +100,7 @@ The Release Engineering subproject is responsible for the [process/procedures](h
 ### Release Team
 The Kubernetes Release Team is responsible for the day-to-day work required to successfully create releases of Kubernetes.
 - **Owners:**
+  - [kubernetes-sigs/release-team-shadow-stats](https://github.com/kubernetes-sigs/release-team-shadow-stats/blob/main/OWNERS)
   - [kubernetes/sig-release/release-team](https://github.com/kubernetes/sig-release/blob/master/release-team/OWNERS)
 - **Contact:**
   - [Mailing List](https://groups.google.com/a/kubernetes.io/g/release-team)
diff --git a/sig-scalability/slos/api_call_latency.md b/sig-scalability/slos/api_call_latency.md
index 45764f9c..ff340929 100644
--- a/sig-scalability/slos/api_call_latency.md
+++ b/sig-scalability/slos/api_call_latency.md
@@ -5,23 +5,31 @@
 | Status | SLI | SLO |
 | --- | --- | --- |
 | __Official__ | Latency<sup>[1](#footnote1)</sup> of mutating<sup>[2](#footnote2)</sup> API calls for single objects for every (resource, verb) pair, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, for every (resource, verb) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day <= 1s |
-| __Official__ | Latency<sup>[1](#footnote1)</sup> of non-streaming read-only<sup>[3](#footnote3)</sup> API calls for every (resource, scope<sup>[4](#footnote4)</sup>) pair, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day (a) <= 1s if `scope=resource` (b) <= 5s if `scope=namespace` (c) <= 30s if `scope=cluster` |
+| __Official__ | Latency<sup>[1](#footnote1)</sup> of non-streaming read-only<sup>[3](#footnote3)</sup> API calls for every (resource, scope<sup>[4](#footnote4)</sup>) pair, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day: (a) <= 1s if `scope=resource` (b) <= 30s<sup>[5](#footnote5)</sup> otherwise (if `scope=namespace` or `scope=cluster`) |
 
-<a name="footnote1">\[1\]</a>By latency of API call in this doc we mean time
+<a name="footnote1">\[1\]</a> By latency of API call in this doc we mean time
 from the moment when apiserver gets the request to last byte of response sent
 to the user.
 
-<a name="footnote2">\[2\]</a>By mutating API calls we mean POST, PUT, DELETE
+<a name="footnote2">\[2\]</a> By mutating API calls we mean POST, PUT, DELETE
 and PATCH.
 
-<a name="footnote3">\[3\]</a>By non-streaming read-only API calls we mean GET
+<a name="footnote3">\[3\]</a> By non-streaming read-only API calls we mean GET
 requests without `watch=true` option set. (Note that in Kubernetes internally
 it translates to both GET and LIST calls).
 
-<a name="footnote4">\[4\]</a>A scope of a request can be either (a) `resource`
-if the request is about a single object, (b) `namespace` if it is about objects
-from a single namespace or (c) `cluster` if it spawns objects from multiple
-namespaces.
+<a name="footnote4">\[4\]</a> A scope of a request can be either
+- `resource` - if the request is about a single object
+- `namespace` - if it is about objects from a single namespace
+- `cluster` - if it spawns objects from multiple namespaces
+
+<a name="footnote5">\[5\]</a> Historically, the threshold for LISTs with
+`scope=namespace` was set to 5 seconds. However, the threshold was chosen when
+Kubernetes didn't support the scale it supports today and when individual
+namespace didn't contain tens of thousands (if not more) objects of a given
+type. We adjusted the limits to accommodate the usage patterns change, given
+that users are fine with listing tens of thousands of objects taking more than
+5 seconds.
 
 ### User stories
 - As a user of vanilla Kubernetes, I want some guarantee how quickly I get the
diff --git a/sig-scalability/slos/slos.md b/sig-scalability/slos/slos.md
index 0cdb576b..ef59a56c 100644
--- a/sig-scalability/slos/slos.md
+++ b/sig-scalability/slos/slos.md
@@ -115,7 +115,7 @@ __TODO: Cluster churn should be moved to scalability thresholds.__
 | Status | SLI | SLO | User stories, test scenarios, ... |
 | --- | --- | --- | --- |
 | __Official__ | Latency of mutating API calls for single objects for every (resource, verb) pair, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, for every (resource, verb) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day<sup>[1](#footnote1)</sup> <= 1s | [Details](./api_call_latency.md) |
-| __Official__ | Latency of non-streaming read-only API calls for every (resource, scope pair, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day<sup>[1](#footnote1)</sup> (a) <= 1s if `scope=resource` (b) <= 5s if `scope=namespace` (c) <= 30s if `scope=cluster` | [Details](./api_call_latency.md) |
+| __Official__ | Latency of non-streaming read-only API calls for every (resource, scope) pair, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day<sup>[1](#footnote1)</sup> (a) <= 1s if `scope=resource` (b) <= 30s otherwise (if `scope=namespace` or `scope=cluster`) | [Details](./api_call_latency.md) |
 | __Official__ | Startup latency of schedulable stateless pods, excluding time to pull images and run init containers, measured from pod creation timestamp to when all its containers are reported as started and observed via watch, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, 99th percentile per cluster-day<sup>[1](#footnote1)</sup> <= 5s | [Details](./pod_startup_latency.md) |
 | __WIP__ | Startup latency of schedulable stateful pods, excluding time to pull images, run init containers, provision volumes (in delayed binding mode) and unmount/detach volumes (from previous pod if needed), measured from pod creation timestamp to when all its containers are reported as started and observed via watch, measured as 99th percentile over last 5 minutes | In default Kubernetes installation, 99th percentile per cluster-day<sup>[1](#footnote1)</sup> <= X where X depends on storage provider | [Details](./pod_startup_latency.md) |
 | __WIP__ | Latency of programming in-cluster load balancing mechanism (e.g. iptables), measured from when service spec or list of its `Ready` pods change to when it is reflected in load balancing mechanism, measured as 99th percentile over last 5 minutes aggregated across all programmers | In default Kubernetes installation, 99th percentile per cluster-day<sup>[1](#footnote1)</sup> <= X | [Details](./network_programming_latency.md) |
diff --git a/sig-scheduling/README.md b/sig-scheduling/README.md
index 82f402a2..74dc7c26 100644
--- a/sig-scheduling/README.md
+++ b/sig-scheduling/README.md
@@ -80,9 +80,6 @@ The following [subprojects][subproject-definition] are owned by sig-scheduling:
 ### kueue
 - **Owners:**
   - [kubernetes-sigs/kueue](https://github.com/kubernetes-sigs/kueue/blob/main/OWNERS)
-### poseidon
-- **Owners:**
-  - [kubernetes-sigs/poseidon](https://github.com/kubernetes-sigs/poseidon/blob/master/OWNERS)
 ### scheduler
 - **Owners:**
   - [kubernetes/kubernetes/cmd/kube-scheduler](https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-scheduler/OWNERS)
diff --git a/sig-security/annual-report-2021.md b/sig-security/annual-report-2021.md
index 9684e8f5..21ce1a59 100644
--- a/sig-security/annual-report-2021.md
+++ b/sig-security/annual-report-2021.md
@@ -1,137 +1,129 @@
-# 2021 Annual Report: SIG Security
+# SIG Security - 2021 annual report
 
 ## Current initiatives
 
-1. What work did the SIG do this year that should be highlighted?
+**1. What work did the SIG do this year that should be highlighted?**
 
-   -
-   -
-   -
+- At the time of the 2020 Annual Reports, SIG Security was a very new SIG, just establishing who we are as a group and starting to build a space for security to flourish as a community effort. In 2021, we have come into our own. Since the last annual report, SIG Security has doubled in size, established and matured subprojects that have become welcoming communities of their own, and grown new leaders who have come to lift up more new contributors themselves. We now have generations of contributors working, learning, and honking together.
 
-2. What initiatives are you working on that aren't being tracked in KEPs?
+  Our [Docs subproject](https://kubernetes.slack.com/archives/C01D8R7ACQ2) has made Kubernetes security more approachable through blogs and tutorials such as [A Closer Look at NSA/CISA Kubernetes Hardening Guidance](https://kubernetes.io/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/), [Securing Admission Controllers](https://kubernetes.io/blog/2022/01/19/secure-your-admission-controllers-and-webhooks/), [Apply Pod Security Standards at the Cluster Level](https://kubernetes.io/docs/tutorials/security/cluster-level-pss/), and [Apply Pod Security Standards at the Namespace Level](https://kubernetes.io/docs/tutorials/security/ns-level-pss/).
 
-   -
-   -
-   -
+  Our [Tooling subproject](https://kubernetes.slack.com/archives/C01CUSVMHPY) got off the ground in 2021 and is now flying high, [standardizing Kubernetes CVE reporting](https://github.com/kubernetes/sig-security/issues/1), [prototyping vulnerability scanning of Kubernetes artifacts](https://github.com/kubernetes/sig-security/issues/3), and [hosting](https://www.youtube.com/watch?v=zB1-7NLsfps) [learning](https://www.youtube.com/watch?v=o-E6aoKmznY) [sessions](https://www.youtube.com/watch?v=MWAb63gf3gs) which have been viewed hundreds of times.
 
-3. KEP work in 2021 (1.x, 1.y, 1.z):
+  SIG Security does things differently than a lot of other SIGs. We don’t own code. We work hard to cultivate and grow an inclusive, welcoming environment where everyone, from the newest contributor to the most experienced hacker, can come share their ideas and contribute to the security of the project. This is designed to ripple outward whether or not we are involved, encouraging and facilitating internal collaboration across SIGs and engagement with the external security community. We’re really proud of how far we’ve come, and we’re excited to continue leading by example into 2022 and beyond!
 
-<!--
-In future, this will be generated from kubernetes/enhancements kep.yaml files
-1. with SIG as owning-sig or in participating-sigs
-2. listing 1.x, 1.y, or 1.z in milestones or in latest-milestone
--->
+**2. What initiatives are you working on that aren't being tracked in KEPs?**
+
+- Most of our work is outside the scope of KEPs. Improving processes, providing ongoing services, and actively building collaboration within the Kubernetes project are all core to what we do. We operate on the basis of consent, communication, and participation–what gets done is based on who shows up, what ideas they bring, and how the rest of the community responds.
+
+  [Security Self-assessments](https://github.com/kubernetes/sig-security/issues/2) are a great example of how this works in practice. ClusterAPI maintainers were looking for guidance on evaluating and improving the security of ClusterAPI, and SIG Security members were enthusiastic about helping them. We collaborated with CNCF TAG Security to begin a guided self-assessment exercise for ClusterAPI, adapting TAG Security’s existing self-assessment workflow into a Kubernetes context. Through this process, the participants have gained confidence and experience, word has gotten around, and other Kubernetes subprojects have started asking about their own guided self-assessments. At the time of this writing, Security Self-Assessment is emerging as a likely new SIG Security subproject.
+
+  Our [Tooling subproject](https://kubernetes.slack.com/archives/C01CUSVMHPY) is working to prototype, define policy for, and implement [vulnerability scanning for build time dependencies and container images](https://github.com/kubernetes/sig-security/issues/3). This initiative involves collaborating with several other SIGs, applying SIG Security’s specialized experience with these tools to produce meaningful improvements without burying other SIGs in additional work.
+
+  Our [Third-Party Audit subproject](https://github.com/kubernetes/sig-security/tree/main/sig-security-external-audit) continues to administer their namesake initiative. In 2021 they published a [Request for Proposals](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021/RFP.md), evaluated the vendor responses, and began to negotiate contract terms with the selected vendor. As of this writing, they have [announced the vendor selection](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021/RFP_Decision.md) and are making arrangements for work to begin.
+
+  Our [Security Docs subproject](https://kubernetes.slack.com/archives/C01D8R7ACQ2) works in collaboration with SIG Docs and others on its continuing initiatives: to improve security representation and content in Kubernetes documentation, to communicate information to help end users and others keep themselves safer, and to help foster and grow new contributors. They have been prolifically publishing useful information such as the blog posts shouted out in the beginning of this report, and highlighting good first issues for new contributors to start diving in.
+
+**3. KEP work in 2021 (1.21, 1.22, 1.23):**
 
    - Stable
-     - [$kep-number - $title](https://git.k8s.io/community/$link/README.md) - $milestone.stable
-     - [$kep-number - $title](https://git.k8s.io/community/$link/README.md) - $milestone.stable
+      - [1933 - Defend against logging secrets via static analysis](https://git.k8s.io/enhancements/keps/sig-security/1933-secret-logging-static-analysis/README.md) - 1.23
    - Beta
-     - [$kep-number - $title](https://git.k8s.io/community/$link/README.md) - $milestone.beta
-     - [$kep-number - $title](https://git.k8s.io/community/$link/README.md) - $milestone.beta
+      - [2579 - PSP Replacement Policy](https://git.k8s.io/enhancements/keps/sig-auth/2579-psp-replacement/README.m) - 1.23
+      - [1933 - Defend against logging secrets via static analysis](https://git.k8s.io/enhancements/keps/sig-security/1933-secret-logging-static-analysis/README.md) - 1.21
    - Alpha
-     - [$kep-number - $title](https://git.k8s.io/community/$link/README.md) - $milestone.alpha
-     - [$kep-number - $title](https://git.k8s.io/community/$link/README.md) - $milestone.alpha
+       - [2579 - PSP Replacement Policy](https://git.k8s.io/enhancements/keps/sig-auth/2579-psp-replacement/README.md) - 1.22
    - Pre-alpha
-     - [$kep-number - $title](https://git.k8s.io/community/$link/README.md)
+      - [2763 - Ambient Capabilities](https://git.k8s.io/enhancements/keps/sig-security/2763-ambient-capabilities/README.md)
 
 ## Project health
 
-1. What areas and/or subprojects does your group need the most help with?
-   Any areas with 2 or fewer OWNERs? (link to more details)
+**1. What areas and/or subprojects does your group need the most help with?**
+
+- Our [Docs subproject](https://kubernetes.slack.com/archives/C01D8R7ACQ2) is always looking for security-minded contributors of all experience levels to share their learning and knowledge with the community! This subproject has consistently been a place where people [merge](https://github.com/kubernetes/website/pull/28248) their [first](https://github.com/kubernetes/website/pull/31518) Kubernetes PRs.There’s always room for continuous improvement in our documentation, and contributing to this provides an opportunity to learn more about Kubernetes security while helping everyone run their clusters more safely. We’re really proud of the way Docs encourages and welcomes new contributors, and we’d love to encourage you to become a part of it!
+
+**Any areas with 2 or fewer OWNERs? (link to more details)**
 
-   -
-   -
-   -
+- The nature of our work means we have little need for OWNERS files, compared to SIGs that ship code. We have two or more OWNERS in all areas, and our community focus helps ensure that when someone needs to scale back their involvement they will be well supported.
 
-2. What metrics/community health stats does your group care about and/or measure?
+**2. What metrics/community health stats does your group care about and/or measure?**
 
-   -
-   -
-   -
+- We care about our people. We measure community health by looking at community participation, and seeing how people are feeling. Are people coming to meetings and talking to one another on Slack? How many people are engaged? Is anyone dominating the conversation? Are new contributors becoming involved? Are people coming back? 
 
-3. Does your [CONTRIBUTING.md] help **new** contributors engage with your group specifically by pointing
-   to activities or programs that provide useful context or allow easy participation?
 
-   -
+  These types of concerns are notably hard to metricize, which we remain comfortable with.
 
-4. If your group has special training, requirements for reviewers/approvers, or processes beyond the general [contributor guide],
-   does your [CONTRIBUTING.md] document those to help **existing** contributors grow throughout the [contributor ladder]?
+**3. Does your [CONTRIBUTING.md] help _new_ contributors engage with your group specifically by pointing to activities or programs that provide useful context or allow easy participation?**
 
-   -
 
-5. Does the group have contributors from multiple companies/affiliations?
+- We have known for some time that SIG Security needs a CONTRIBUTING.MD document that more accurately reflects how we do things. SIG Security takes a community-building approach to improving Kubernetes security: we intentionally make a space where someone can begin contributing by sharing their thoughts and ideas in a meeting or Slack message. The CONTRIBUTING.MD document we have in progress reflects this. It encourages participation by showing up and links to the general Kubernetes contributor guides, which are still applicable.
 
-   -
+**4. If your group has special training, requirements for reviewers/approvers, or processes beyond the general [contributor guide], does your [CONTRIBUTING.md] document those to help _existing_ contributors grow throughout the [contributor ladder]?**
 
-6. Are there ways end users/companies can contribute that they currently are not?
-   If one of those ways is more full time support, what would they work on and why?
+- SIG Security does not have special training or requirements for reviewers/approvers. The nature of our cross-SIG work means that we have many fewer PRs, OWNERS files, and similar artifacts than many SIGs. The Kubernetes Contributor Ladder document as currently written focuses on scaling review of numerous code PRs. This limits its immediate applicability to our horizontal SIG, which does not own code and is intentionally built upon open, non-hierarchical community participation. We continue to learn through experience how best to utilize and evolve the contributor ladder to encourage and recognize our leading contributors.
 
-   -
-   -
+**5. Does the group have contributors from multiple companies/affiliations?**
+
+   - Yes.
+
+**6. Are there ways end users/companies can contribute that they currently are not? If one of those ways is more full time support, what would they work on and why?**
+
+   - End users and people who work at end user companies are contributing broadly within SIG Security today. There are so many possibilities of ways to contribute. As a community we continue to experiment and discover new ways, together. Bring your gifts; come share and learn with us!
 
 ## Membership
 
-- Primary slack channel member count:
-- Primary mailing list member count:
-- Primary meeting attendee count (estimated, if needed):
-- Primary meeting participant count (estimated, if needed):
-- Unique reviewers for SIG-owned packages: <!-- in future, this will be generated from OWNERS files referenced from subprojects, expanded with OWNERS_ALIASES files -->
-- Unique approvers for SIG-owned packages: <!-- in future, this will be generated from OWNERS files referenced from subprojects, expanded with OWNERS_ALIASES files -->
+- Primary slack channel member count: 890
+- Subproject slack channel member counts:
+  - #sig-security-docs: 260
+  - #sig-security-tooling: 357
+- Primary mailing list member count: 246
+- Primary meeting attendee count (estimated, if needed): 13.8
+- Primary meeting participant count (estimated, if needed): 13.8
 
-Include any other ways you measure group membership
+Due to the way we conduct our meetings, at the majority of meetings, everyone participates.
 
-## Subprojects
+- Unique reviewers for SIG-owned packages: N/A
+- Unique approvers for SIG-owned packages: N/A
 
-<!--
-In future, this will be generated from delta of sigs.yaml from $YYYY-01-01 to $YYYY-12-31
-Manually visible via `git diff HEAD@{$YYYY-01-01} HEAD@{$YYYY-12-31} -- $sig-id/README.md`
--->
+SIG Security does not own packages.
 
-New in $YYYY:
-- [$subproject-name](https://git.k8s.io/community/$sig-id#$subproject-name)
--
+## Subprojects
+
+New in 2021:
+- [security-tooling](https://git.k8s.io/community/sig-security#security-tooling)
 
-Retired in $YYYY:
-- [$subproject-name](https://git.k8s.io/community/$sig-id#$subproject-name)
--
+Retired in 2021:
+- none
 
 Continuing:
-- [$subproject-name](https://git.k8s.io/community/$sig-id#$subproject-name)
--
+- [security-audit](https://git.k8s.io/community/sig-security#$security-audit)
+- [security-docs](https://git.k8s.io/community/sig-security#$security-docs)
 
 ## Working groups
 
-<!--
-In future, this will be generated from delta of sigs.yaml from $YYYY-01-01 to $YYYY-12-31
-Manually visible via `git diff HEAD@{$YYYY-01-01} HEAD@{$YYYY-12-31} -- $sig-id/README.md`
--->
+New in 2021:
+- none
 
-New in $YYYY:
-- [$wg-name](https://git.k8s.io/community/$wg-id/) ([$YYYY report](https://git.k8s.io/community/$wg-id/annual-report-$YYYY.md))
--
-
-Retired in $YYYY:
-- [$wg-name](https://git.k8s.io/community/$wg-id/) ([$YYYY report](https://git.k8s.io/community/$wg-id/annual-report-$YYYY.md))
--
+Retired in 2021:
+- none
 
 Continuing:
-- [$wg-name](https://git.k8s.io/community/$wg-id/) ([$YYYY report](https://git.k8s.io/community/$wg-id/annual-report-$YYYY.md))
--
+- none
 
 ## Operational
 
 Operational tasks in [sig-governance.md]:
 
-- [ ] [README.md] reviewed for accuracy and updated if needed
+- [x] [README.md] reviewed for accuracy and updated if needed
 - [ ] [CONTRIBUTING.md] reviewed for accuracy and updated if needed
-      (or created if missing and your contributor steps and experience are different or more
-      in-depth than the documentation listed in the general [contributor guide] and [devel] folder.)
-- [ ] Subprojects list and linked OWNERS files in [sigs.yaml] reviewed for accuracy and updated if needed
-- [ ] SIG leaders (chairs, tech leads, and subproject owners) in [sigs.yaml] are accurate and active, and updated if needed
-- [ ] Meeting notes and recordings for 2021 are linked from [README.md] and updated/uploaded if needed
-- [ ] Did you have community-wide updates in 2021 (e.g. community meetings, kubecon, or kubernetes-dev@ emails)? Links to email, slides, or recordings:
-      -
-      -
+    (or created if missing and your contributor steps and experience are different or more
+    in-depth than the documentation listed in the general [contributor guide] and [devel] folder.)
+- [x] Subprojects list and linked OWNERS files in [sigs.yaml] reviewed for accuracy and updated if needed
+- [x] SIG leaders (chairs, tech leads, and subproject owners) in [sigs.yaml] are accurate and active, and updated if needed
+- [x] Meeting notes and recordings for 2021 are linked from [README.md] and updated/uploaded if needed
+- [x] Did you have community-wide updates in 2021 (e.g. community meetings, kubecon, or kubernetes-dev@ emails)? Links to email, slides, or recordings:
+    - KubeCon EU: [Get In Containerds, We’re Going Securing: Kubernetes SIG Security is Here!](https://www.youtube.com/watch?v=0_s6zkyRpME)
+    - KubeCon NA: [Security Through Transparency: Kubernetes SIG Security Update](https://www.youtube.com/watch?v=O5Wy7zSigOU)
 
 [CONTRIBUTING.md]: https://git.k8s.io/community/sig-security/CONTRIBUTING.md
 [contributor ladder]: https://git.k8s.io/community/community-membership.md
@@ -140,4 +132,3 @@ Operational tasks in [sig-governance.md]:
 [sigs.yaml]: https://git.k8s.io/community/sigs.yaml
 [contributor guide]: https://git.k8s.io/community/contributors/guide/README.md
 [devel]: https://git.k8s.io/community/contributors/devel/README.md
-
diff --git a/sigs.yaml b/sigs.yaml
index 6683ec49..cabbf56d 100644
--- a/sigs.yaml
+++ b/sigs.yaml
@@ -906,8 +906,8 @@ sigs:
     - description: Regular IBM Subproject Meeting
       day: Wednesday
       time: "14:00"
-      tz: EST
-      frequency: biweekly
+      tz: ET (Eastern Time)
+      frequency: monthly - last Wednesday every month
       url: https://zoom.us/j/9392903494
       archive_url: https://docs.google.com/document/d/1qd_LTu5GFaxUhSWTHigowHt3XwjJVf1L57kupj8lnwg/edit
   - name: provider-openstack
@@ -2086,7 +2086,7 @@ sigs:
       company: Chainguard, Inc
     - github: jeremyrickard
       name: Jeremy Rickard
-      company: Apple
+      company: Microsoft
     - github: puerco
       name: Adolfo García Veytia
       company: Chainguard, Inc
@@ -2182,6 +2182,7 @@ sigs:
       - name: release-team-leads
         description: Release Team Leads for the current Kubernetes release cycle
     owners:
+    - https://raw.githubusercontent.com/kubernetes-sigs/release-team-shadow-stats/main/OWNERS
     - https://raw.githubusercontent.com/kubernetes/sig-release/master/release-team/OWNERS
   - name: SIG Release Process Documentation
     description: |
@@ -2355,9 +2356,6 @@ sigs:
   - name: kueue
     owners:
     - https://raw.githubusercontent.com/kubernetes-sigs/kueue/main/OWNERS
-  - name: poseidon
-    owners:
-    - https://raw.githubusercontent.com/kubernetes-sigs/poseidon/master/OWNERS
   - name: scheduler
     owners:
     - https://raw.githubusercontent.com/kubernetes/kubernetes/master/cmd/kube-scheduler/OWNERS
diff --git a/wg-data-protection/annual-report-2021.md b/wg-data-protection/annual-report-2021.md
index d3d281e5..31197f2c 100644
--- a/wg-data-protection/annual-report-2021.md
+++ b/wg-data-protection/annual-report-2021.md
@@ -1,44 +1,55 @@
 # 2021 Annual Report: WG Data Protection
 
+Note: Only include KEPs targeting 1.21, 1.22, and 1.23 releases.
+
 ## Current initiatives
 
 1. What work did the WG do this year that should be highlighted?
    For example, artifacts, reports, white papers produced this year.
 
-   -
-   -
-   -
+- [Data Protection White Paper](https://github.com/kubernetes/community/blob/master/wg-data-protection/data-protection-workflows-white-paper.md)
+- KEPs being worked on:
+  - Restrict volume mode conversion to fix security issue: Had discussions in the WG and submitted KEP to introduce it as an Alpha feature: https://github.com/kubernetes/enhancements/pull/3151
+  - Working on moving Volume Populator to Beta: https://github.com/kubernetes/enhancements/pull/2934
+  - Object Storage API (COSI): KEP is being updated and reviewed: https://github.com/kubernetes/enhancements/pull/2813
+  - ContainerNotifier KEP review in progress: https://github.com/kubernetes/enhancements/pull/1995/
+  - Volume Group KEP review in progress: https://github.com/kubernetes/enhancements/pull/1551
 
 2. What initiatives are you working on that aren't being tracked in KEPs?
 
-   -
-   -
-   -
+We discussed the following topics in the WG that are not tracked in KEPs:
+- Change Block Tracking (CBT) API design: https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#heading=h.1olwavha9frv
+- Volume Replication: https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#heading=h.pah3yke9ddug
+- Backup and restore externally managed services:
+  - https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#heading=h.7zwanijz69u1
+  - https://docs.google.com/presentation/d/1IM6d0w3CDdHv1dLaFNXEcxy5fuDTr9LERAdMVkZiK9s/edit#slide=id.p
+- Snapshot policy (immutable snapshot): https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#heading=h.gb8m7t8jro1v
+- Securing S3 Backups against Ransomware: https://sched.co/igUT
+- Volume Snapshot GA phases: https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#heading=h.w8v8tpkuw8ac
+- Kubernetes Data Protection with Velero: https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#heading=h.iekhl8nl58lo
 
 ## Project health
 
 1. What's the current roadmap until completion of the working group?
 
-   -
-   -
-   -
+We have identified the missing building blocks for supporting Data Protection in Kubernetes in our white paper: https://github.com/kubernetes/community/blob/master/wg-data-protection/data-protection-workflows-white-paper.md#what-are-the-missing-building-blocks-in-kubernetes. Features such as Volume Backups, Change Block Tracking, Volume Populator, Volume Group and Group Snapshot, and Backup Repositories are owned by SIG Storage. Features such as Quiesce and Unquiesce Hooks are owned by SIG Node, with SIG Storage and SIG Apps participating. Features such as Application Snapshots and Backups are owned by SIG Apps, with SIG Storage participating. We will continue to work on them until all the missing pieces are available in Kubernetes.
 
 2. Does the group have contributors from multiple companies/affiliations?
 
-   -
+Yes. In our [agenda doc](https://docs.google.com/document/d/15tLCV3csvjHbKb16DVk-mfUmFry_Rlwo-2uG6KNGsfw/edit#), we listed companies who are supporting the WG. Here are some of the companies that actively participating in the WG: Cohesity, Dell EMC, Druva, Google, Infinidat, Kasten by Veeam, Microsoft, Mirantis, NetApp, Red Hat, Seagate, Trilio, Veritas, and VMware.
 
 3. Are there ways end users/companies can contribute that they currently are not?
    If one of those ways is more full time support, what would they work on and why?
 
-   -
-   -
+- There were a couple of end users who participated in the meeting and brought up topics such as how to backup and restore externally managed services.
+- If more end users/companies can attend our meetings, provide feedback, and contribute to design/implementation of the features we are working on, that will be great.
 
 ## Membership
 
-- Primary slack channel member count:
-- Primary mailing list member count:
-- Primary meeting attendee count (estimated, if needed):
-- Primary meeting participant count (estimated, if needed):
+- Primary slack channel member count: 196
+- Primary mailing list member count: 193
+- Primary meeting attendee count (estimated, if needed): 25
+- Primary meeting participant count (estimated, if needed): 25
 
 Include any other ways you measure group membership
 
@@ -46,17 +57,20 @@ Include any other ways you measure group membership
 
 Operational tasks in [wg-governance.md]:
 
-- [ ] [README.md] reviewed for accuracy and updated if needed
-- [ ] WG leaders in [sigs.yaml] are accurate and active, and updated if needed
-- [ ] Meeting notes and recordings for 2021 are linked from [README.md] and updated/uploaded if needed
-- [ ] Updates provided to sponsoring SIGs in 2021
-      - [$sig-name](https://git.k8s.io/community/$sig-id/)
+- [x] [README.md] reviewed for accuracy and updated if needed
+- [x] WG leaders in [sigs.yaml] are accurate and active, and updated if needed
+- [x] Meeting notes and recordings for 2021 are linked from [README.md] and updated/uploaded if needed
+- [x] Updates provided to sponsoring SIGs in 2021
+      - [sig-storage](https://git.k8s.io/community/sig-storage)
         - links to email, meeting notes, slides, or recordings, etc
+        - WG does not own code. We discussed the features such as CBT, Volume Populator in the WG meeting, but we still get the features tracked in SIG Storage and they are in the tracking spreadsheet. This means we’ll give an update on them in every SIG Storage bi-weekly meeting:  https://docs.google.com/spreadsheets/d/1t4z5DYKjX2ZDlkTpCnp18icRAQqOE85C1T1r2gqJVck/edit#gid=705655608
       - [$sig-name](https://git.k8s.io/community/$sig-id/)
         - links to email, meeting notes, slides, or recordings, etc
-      -
+- KubeCon updates
+  - KubeCon Europe 2021: https://www.youtube.com/watch?v=DBxOBzBkimo
+  - KubeCon NA 2021: https://www.youtube.com/watch?v=pTDWiHmpEz8&t=4s
+  - KubeCon China 2021: https://www.youtube.com/watch?v=rHRhmi76Q4I
 
 [wg-governance.md]: https://git.k8s.io/community/committee-steering/governance/wg-governance.md
 [README.md]: https://git.k8s.io/community/wg-data-protection/README.md
 [sigs.yaml]: https://git.k8s.io/community/sigs.yaml
-