Fix do not disrupt annotation race condition and removal of disruption candidates

.github/actions/install-deps/action.yaml

@@ -16,7 +16,7 @@ runs:
     # Root path permission workaround for caching https://github.com/actions/cache/issues/845#issuecomment-1252594999
     - run: sudo chown "$USER" /usr/local
       shell: bash
-    - uses: actions/cache@ab5e6d0c87105b4c9c2047343972218f562e4319 # v4.0.1
+    - uses: actions/cache@0c45773b623bea8c8e75f6c82b208c3cf94ea4f9 # v4.0.2
       id: cache-toolchain
       with:
         path: |

.github/workflows/codeql-analysis.yaml

@@ -17,7 +17,7 @@ jobs:
       actions: read # github/codeql-action/init@v2
       security-events: write # github/codeql-action/init@v2
     steps:
-      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
       - uses: ./.github/actions/install-deps
       - run: make vulncheck
       - uses: github/codeql-action/init@df32e399139a3050671466d7d9b3cbacc1cfd034 # v2.22.8
@@ -34,7 +34,7 @@ jobs:
       actions: read # github/codeql-action/init@v2
       security-events: write # github/codeql-action/init@v2
     steps:
-      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
       - uses: github/codeql-action/init@df32e399139a3050671466d7d9b3cbacc1cfd034 # v2.22.8
         with:
           languages: javascript

.github/workflows/presubmit.yaml

@@ -15,7 +15,7 @@ jobs:
         matrix:
           k8sVersion: ["1.23.x", "1.24.x", "1.25.x", "1.26.x", "1.27.x", "1.28.x", "1.29.x"]
     steps:
-    - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+    - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
     - uses: ./.github/actions/install-deps
       with:
         k8sVersion: ${{ matrix.k8sVersion }}

.github/workflows/release.yaml

@@ -13,7 +13,7 @@ jobs:
       id-token: write # Needed for cosigning build attestation files with tejolote
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
         with:
           fetch-depth: 0
 
@@ -32,7 +32,7 @@ jobs:
           prerelease: false
 
       - name: Install tejolote
-        uses: kubernetes-sigs/release-actions/setup-tejolote@10fecc1c66829d291b2f2fb1a27329d152f212e6 # v0.1.3
+        uses: kubernetes-sigs/release-actions/setup-tejolote@841d76a188a7c121231a863572e27012805715a2 # v0.1.4
       - name: Run tejolote
         run: |
           tejolote attest "github://kubernetes-sigs/karpenter/${{ github.run_id }}" --artifacts "github://kubernetes-sigs/karpenter/$TAG" --output karpenter.intoto.json --sign

Makefile

@@ -1,6 +1,6 @@
 # This is the format of an AWS ECR Public Repo as an example.
 export KWOK_REPO ?= ${ACCOUNT_ID}.dkr.ecr.${DEFAULT_REGION}.amazonaws.com
-export SYSTEM_NAMESPACE=kube-system
+export KARPENTER_NAMESPACE=kube-system
 
 HELM_OPTS ?= --set logLevel=debug \
 			--set controller.resources.requests.cpu=1 \
@@ -31,7 +31,7 @@ build: ## Build the Karpenter KWOK controller images using ko build
 apply: verify build ## Deploy the kwok controller from the current state of your git repository into your ~/.kube/config cluster
 	hack/validation/kwok-requirements.sh
 	kubectl apply -f pkg/apis/crds
-	helm upgrade --install karpenter kwok/charts --namespace kube-system --skip-crds \
+	helm upgrade --install karpenter kwok/charts --namespace $(KARPENTER_NAMESPACE) --skip-crds \
 		$(HELM_OPTS) \
 		--set controller.image.repository=$(IMG_REPOSITORY) \
 		--set controller.image.tag=$(IMG_TAG) \
@@ -40,7 +40,7 @@ apply: verify build ## Deploy the kwok controller from the current state of your
 		--set-string controller.env[0].value=true
 
 delete: ## Delete the controller from your ~/.kube/config cluster
-	helm uninstall karpenter --namespace ${KARPENTER_NAMESPACE}
+	helm uninstall karpenter --namespace $(KARPENTER_NAMESPACE)
 
 test: ## Run tests
 	go test ./... \

README.md

@@ -15,6 +15,11 @@ Karpenter improves the efficiency and cost of running workloads on Kubernetes cl
 * **Provisioning** nodes that meet the requirements of the pods
 * **Removing** the nodes when the nodes are no longer needed
 
+## Supported CloudProviders 
+Karpenter is a multi-cloud project supported on the following cloud providers 
+- [AWS](https://github.com/aws/karpenter-provider-aws)
+- [Azure](https://github.com/Azure/karpenter-provider-azure)
+
 ## Community, discussion, contribution, and support
 
 If you have any questions or want to get the latest project news, you can connect with us in the following ways:
@@ -43,4 +48,4 @@ Participation in the Kubernetes community is governed by the [Kubernetes Code of
 - 11/30/2021 [Karpenter vs Kubernetes Cluster Autoscaler](https://youtu.be/3QsVRHVdOnM)
 - 11/19/2021 [Karpenter @ Container Day](https://youtu.be/qxWJRUF6JJc)
 - 05/14/2021 [Groupless Autoscaling with Karpenter @ Kubecon](https://www.youtube.com/watch?v=43g8uPohTgc)
-- 05/04/2021 [Karpenter @ Container Day](https://youtu.be/MZ-4HzOC_ac?t=7137)
+- 05/04/2021 [Karpenter @ Container Day](https://youtu.be/MZ-4HzOC_ac?t=7137)

contributing-guidelines.md

@@ -0,0 +1,95 @@
+# Karpenter - Contributor Ladder
+
+This document’s goal is to define clear, scalable, and transparent criteria to support community members to grow responsibility in Karpenter. This document also intends to capture a leadership path for contributors that intend to provide a sustained contribution to Karpenter by taking on reviewer and approver responsibilities at various levels. 
+
+Ultimately, the criteria in this doc is aspirational. No set of written requirements can encapsulate the full criteria when determining if someone meets the bar to be a reviewer or approver, as some of the criteria are subjective and relies on the trust that each nominee has established with the community. To help guide readers, this document outlines ways to demonstrate expertise of the code base, sound judgement on decision tradeoffs, end user advocacy, care for community, and ability to work as a distributed team.
+
+Much of this document uses the [SIG-Node Contributor Ladder](https://github.com/kubernetes/community/blob/master/sig-node/sig-node-contributor-ladder.md) as prior art. The goal is to mold these requirements to fit the Karpenter’s community. These requirements also lean on the established Kubernetes[membership documentation](https://github.com/kubernetes/community/blob/master/community-membership.md) for terminology.
+
+As a final precursor, to become a reviewer or approver, users must nominate themselves. They are responsible for cutting a PR to the upstream repository, providing evidence in-line with the suggested requirements. Users should feel free to reach out to an existing approver to understand what how they land in respect to the criteria. The following sections are guiding criteria and guidelines, where the final decision lies with the maintainers. 
+
+## Reviewers and Approvers
+
+As an autoscaler, Karpenter is responsible for minimizing cost, maximizing application runtime, and automatically updating nodes. Its role as a critical cluster component managed by users sets a high bar for contributions and prioritizes efficiency, operationalization, and simplicity for its users. 
+
+At a high level, reviewers and approvers should be inclined to scrutinize the cost-benefit tradeoffs for level of maintenance versus user-benefit, which may materialize as a bias to say “no” in reviews and design discussions. Reviewers should have an initial bias towards coding over reviews to demonstrate a baseline for knowledge of code base. In design discussions, reviewers and approvers should aim to maintain Karpenter’s efficiency, operationalization, and efficiency. 
+
+Karpenter is a customer driven project, building solutions for real customer problems, and delaying solving theoretical ones. Reviewers and approvers should represent these tenets by minimizing changes to Karpenter’s API surface. No API is the best API, as an un-used or dead API becomes a burden for users to reason about, and a further burden for Karpenter users to maintain.
+
+Lastly, as a library vended for and consumed by cloud providers, Karpenter aims to foster participation from all active cloud providers. Karpenter’s set of reviewers and approvers should have representatives from well known cloud provider implementations, as changes to upstream Karpenter can affect all dependent cloud provider implementations.
+
+To become a reviewer or approver, a user should begin by cutting an issue to track the approval process.
+
+### Reviewers
+
+Reviewer status is an indication that the person is committed to Karpenter activities, demonstrates technical depth, has accumulated enough context, and is overall trustworthy to help inform approvers and aid contributors by applying a lgtm. Anyone is welcome to review a PR with a comment or feedback even if they do not have rights to apply a lgtm. The requirements listed in the [membership document](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer) highlight this as well.
+
+The following is a guiding set of criteria for considering a user eligible to be a reviewer:
+
+* Committed - proof of sustained contributions
+* Be a [Kubernetes org member](https://github.com/kubernetes/community/blob/master/community-membership.md#member) (which has its [own set of requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#requirements))
+* Active Karpenter member for at least 6 months
+* Demonstrates technical depth
+* Primary reviewer for at least 5 PRs to the codebase
+* Reviewed or merged at least 10 non-trivial substantial PRs to the codebase
+* Knowledgeable about the codebase
+* Reliable and builds consensus - established trust with the community
+* Sponsored by an approver
+* With no objections from other approvers
+
+#### Committed
+
+A user’s commitment should be established by looking at PR review history. Committed users should be participating in Karpenter meetings or other ad-hoc meetings that arise when tackling specific problems (exceptions are allowed for cases when timezone or other personal limitations are not allowing for the meeting participation). 
+
+#### Technically sound
+
+Proof of primary reviewership and significant contributions must be provided. Nominees must provide the list of PRs (at least 5 for primary reviewer and 10 substantial PRs authored or reviewed) as suggested in the membership document. Here are additional comments for this list of PRs:
+
+* Reviewed PRs must be merged.
+* Since the purpose is to demonstrate the nominee's technical depth, PRs like analyzer warnings fixes, mechanical “find/replace”-type PRs, minor improvements of logging and insignificant bug fixes are valued, but not counted towards the reviewer status nomination. Lack of reviews of those PRs may be a red flag for nomination approval.
+* A primary reviewer should drive the review of the PR without significant input / guidance from the approver or other reviewers.
+
+It is hard to assess codebase knowledge and it always will be a judgement call. Karpenter will rely on the listed PRs to ensure the person reviewed PRs from different areas of the codebase and on the comments made during Karpenter meetings.
+
+Additional ways to establish the knowledge of context are:
+
+* Contributions to Karpenter documentation
+* Blog posts - k8s-hosted and external
+* Contributions to other adjacent sub-projects within SIG Autoscaling
+
+#### Trustworthy
+
+Reviewer nominations are accepted by Karpenter approvers. Karpenter approvers take nominations seriously and are invested in building a healthy community. Nominees should help approvers understand their future goals in the community so we can help continue to build trust and mutual relationships and nurture new opportunities if and when a contributor wants to become an approver!
+
+### Approvers 
+
+Karpenter approvers have a lot of responsibilities. It is expected that a Karpenter approver keeps the codebase quality high by giving feedback, thoroughly reviewing code, and giving recommendations to Karpenter members and reviewers. Karpenter approvers are essentially gatekeepers to keep the code base at high quality. Karpenter maintains a rigidly high bar for becoming a Karpenter approver by developing trust in a community and demonstrating expertise with a bias towards initial code contributions over reviewing PRs.
+
+We expect at this stage of Karpenter maturity for approvers to have a strong bias to say “no” to unneeded changes or improvements that don't clearly articulate and demonstrate broad benefits. As an autoscaler, approvers have a responsibility to evaluate changes or improvements at scale. [While scale dimensions and thresholds are complex](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md#kubernetes-thresholds), approvers should consider how changes may impact Karpenter's scalability and have a bias for “no” when any of these dimension's scalability is compromised. It also means that the velocity of new features may be affected by this bias. Our continuous work to improve the reliability of the codebase will help to maintain feature velocity going forward.
+
+While evaluating a nomination for approval, nominees may be asked to provide examples of strict scrutiny. Strict scrutiny refers to instances where a performance regression, vulnerability, or complex unintended interaction could have occurred. We do not expect existing approvers or nominees to be perfect (no one is!) but as a maintainer community we have had instances of pull requests that we want to learn from and spot to mitigate potential risks given our trust to users and existing project maturity level. Where specific examples are not present for a nominee (which is fine), we may privately share examples from our past experience for warning signs.
+
+In addition to the formal requirements for the [approver role](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), Karpenter makes these recommendations for nominees for the Karpenter approver status on how to demonstrate expertise and develop trust. Ideally approver rights in more than one of these is **desired but not required**. This is a means of earning trust to existing approvers. 
+
+#### Deep expertise across multiple core controllers 
+
+* Demonstrated influence across multiple core controllers (e.g. provisioning, disruption, cluster state, etc.)
+* Troubleshooting complex issues that touch require a holistic understanding of the code base, with an understanding of common 3rd party use-cases and tooling.
+* Create and merge major code simplification and/or optimization PRs indicating deep understanding of tradeoffs taken and validation of potential side effects.
+
+#### Proficient in features development
+
+* Drive a few major features at all three stages:
+    * “alpha” - design proposal and discussions
+    * “beta” - initial customer feedback collection
+    * “GA/deprecation” - stabilizing feature, following PRs, or managing deprecation.
+* Demonstrate ability to stage changes and pass PRs keeping the end user experience and Kubernetes reliability as top priorities.
+* Be a reviewer for a few major features and demonstrate meaningful participation in the review process.
+* Give actionable feedback for the features and initial proposals during the Karpenter meetings.
+
+#### Active community support
+
+* Have approval rights in a well-known cloud provider implementation of Karpenter or in an adjacent SIG Autoscaling sub-project. 
+* Be a primary PR reviewer for numerous PRs in multiple areas listed as a requirement for a reviewer.
+* Actively triage issues and PRs, provide support to contributors to drive their PRs to completion.
+* Be present, and participate in Karpenter meetings by speaking about features or improvements driven, or find some other way to prove the identity behind GitHub handle.

go.mod

@@ -5,13 +5,13 @@ go 1.22
 require (
 	github.com/Pallinder/go-randomdata v1.2.0
 	github.com/avast/retry-go v3.0.0+incompatible
-	github.com/docker/docker v25.0.4+incompatible
+	github.com/docker/docker v26.0.0+incompatible
 	github.com/go-logr/logr v1.4.1
 	github.com/go-logr/zapr v1.3.0
 	github.com/imdario/mergo v0.3.16
 	github.com/mitchellh/hashstructure/v2 v2.0.2
-	github.com/onsi/ginkgo/v2 v2.16.0
-	github.com/onsi/gomega v1.31.1
+	github.com/onsi/ginkgo/v2 v2.17.1
+	github.com/onsi/gomega v1.32.0
 	github.com/patrickmn/go-cache v2.1.0+incompatible
 	github.com/prometheus/client_golang v1.19.0
 	github.com/prometheus/client_model v0.6.0
@@ -21,15 +21,15 @@ require (
 	golang.org/x/sync v0.6.0
 	golang.org/x/text v0.14.0
 	golang.org/x/time v0.5.0
-	k8s.io/api v0.29.2
-	k8s.io/apiextensions-apiserver v0.29.2
-	k8s.io/apimachinery v0.29.2
-	k8s.io/client-go v0.29.2
-	k8s.io/cloud-provider v0.29.2
-	k8s.io/component-base v0.29.2
-	k8s.io/csi-translation-lib v0.29.2
+	k8s.io/api v0.29.3
+	k8s.io/apiextensions-apiserver v0.29.3
+	k8s.io/apimachinery v0.29.3
+	k8s.io/client-go v0.29.3
+	k8s.io/cloud-provider v0.29.3
+	k8s.io/component-base v0.29.3
+	k8s.io/csi-translation-lib v0.29.3
 	k8s.io/klog/v2 v2.120.1
-	k8s.io/utils v0.0.0-20230726121419-3b25d923346b
+	k8s.io/utils v0.0.0-20240102154912-e7106e64919e
 	knative.dev/pkg v0.0.0-20230712131115-7051d301e7f4
 	sigs.k8s.io/controller-runtime v0.17.2
 )
@@ -56,7 +56,7 @@ require (
 	github.com/gobuffalo/flect v0.2.4 // indirect
 	github.com/gogo/protobuf v1.3.2 // indirect
 	github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
-	github.com/golang/protobuf v1.5.3 // indirect
+	github.com/golang/protobuf v1.5.4 // indirect
 	github.com/google/gnostic-models v0.6.8 // indirect
 	github.com/google/go-cmp v0.6.0 // indirect
 	github.com/google/gofuzz v1.2.0 // indirect
@@ -83,18 +83,18 @@ require (
 	go.uber.org/atomic v1.10.0 // indirect
 	go.uber.org/automaxprocs v1.4.0 // indirect
 	golang.org/x/exp v0.0.0-20220722155223-a9213eeb770e // indirect
-	golang.org/x/net v0.20.0 // indirect
+	golang.org/x/net v0.23.0 // indirect
 	golang.org/x/oauth2 v0.16.0 // indirect
-	golang.org/x/sys v0.16.0 // indirect
-	golang.org/x/term v0.16.0 // indirect
+	golang.org/x/sys v0.18.0 // indirect
+	golang.org/x/term v0.18.0 // indirect
 	golang.org/x/tools v0.17.0 // indirect
 	gomodules.xyz/jsonpatch/v2 v2.4.0 // indirect
 	google.golang.org/api v0.124.0 // indirect
 	google.golang.org/appengine v1.6.7 // indirect
 	google.golang.org/genproto/googleapis/api v0.0.0-20230726155614-23370e0ffb3e // indirect
 	google.golang.org/genproto/googleapis/rpc v0.0.0-20230822172742-b8732ec3820d // indirect
 	google.golang.org/grpc v1.58.3 // indirect
-	google.golang.org/protobuf v1.32.0 // indirect
+	google.golang.org/protobuf v1.33.0 // indirect
 	gopkg.in/inf.v0 v0.9.1 // indirect
 	gopkg.in/yaml.v2 v2.4.0 // indirect
 	gopkg.in/yaml.v3 v3.0.1 // indirect
@@ -106,5 +106,7 @@ require (
 
 retract (
 	v0.100.101-test // accidentally published testing version
+	v0.35.3 // accidentally published incomplete patch release
+	v0.34.4 // accidentally published incomplete patch release
 	v0.27.7 // accidentally published incomplete patch release
 )