Bump to k8s 1.32.3 (#1318)

This change bumps k8s to 1.32.3 and also bumps other direct
dependencies.

Co-authored-by: Jiri Mencak <[email protected]>

Author: jmencak

go.mod

@@ -20,6 +20,7 @@ spec:
     containerRuntimeEndpoint: ""
     cpuManagerPolicy: static
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

go.sum

@@ -20,6 +20,7 @@ spec:
     containerRuntimeEndpoint: ""
     cpuManagerPolicy: static
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/bootstrap/extra-mcp/openshift-bootstrap-master_kubeletconfig.yaml

@@ -20,6 +20,7 @@ spec:
     containerRuntimeEndpoint: ""
     cpuManagerPolicy: static
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/bootstrap/extra-mcp/openshift-bootstrap-worker_kubeletconfig.yaml

@@ -20,6 +20,7 @@ spec:
     containerRuntimeEndpoint: ""
     cpuManagerPolicy: static
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/bootstrap/no-mcp/openshift-bootstrap-master_kubeletconfig.yaml

@@ -20,6 +20,7 @@ spec:
     cpuManagerPolicyOptions:
       full-pcpus-only: "true"
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/bootstrap/no-mcp/openshift-bootstrap-worker_kubeletconfig.yaml

@@ -20,6 +20,7 @@ spec:
     cpuManagerPolicyOptions:
       full-pcpus-only: "true"
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/default/arm/manual_kubeletconfig.yaml

@@ -22,6 +22,7 @@ spec:
     cpuManagerPolicyOptions:
       full-pcpus-only: "true"
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/default/cpuFrequency/manual_kubeletconfig.yaml

@@ -22,6 +22,7 @@ spec:
     cpuManagerPolicyOptions:
       full-pcpus-only: "true"
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/default/manual_kubeletconfig.yaml

@@ -20,6 +20,7 @@ spec:
     cpuManagerPolicyOptions:
       full-pcpus-only: "true"
     cpuManagerReconcilePeriod: 5s
+    crashLoopBackOff: {}
     evictionHard:
       imagefs.available: 15%
       memory.available: 100Mi

test/e2e/performanceprofile/testdata/render-expected-output/default/pp-norps/manual_kubeletconfig.yaml

@@ -0,0 +1,2 @@
+7.0.1
+# Keep this pinned version in parity with cel-go

test/e2e/performanceprofile/testdata/render-expected-output/no-ref/manual_kubeletconfig.yaml

@@ -0,0 +1,2 @@
+*.pb.go linguist-generated=true
+*.pb.go -diff -merge

vendor/cel.dev/expr/.bazelversion

@@ -0,0 +1,2 @@
+bazel-*
+MODULE.bazel.lock

vendor/cel.dev/expr/.gitattributes

@@ -0,0 +1,34 @@
+load("@io_bazel_rules_go//go:def.bzl", "go_library")
+
+package(default_visibility = ["//visibility:public"])
+
+licenses(["notice"])  # Apache 2.0
+
+go_library(
+    name = "expr",
+    srcs = [
+        "checked.pb.go",
+        "eval.pb.go",
+        "explain.pb.go",
+        "syntax.pb.go",
+        "value.pb.go",
+    ],
+    importpath = "cel.dev/expr",
+    visibility = ["//visibility:public"],
+    deps = [
+        "@org_golang_google_genproto_googleapis_rpc//status:go_default_library",
+        "@org_golang_google_protobuf//reflect/protoreflect",
+        "@org_golang_google_protobuf//runtime/protoimpl",
+        "@org_golang_google_protobuf//types/known/anypb",
+        "@org_golang_google_protobuf//types/known/durationpb",
+        "@org_golang_google_protobuf//types/known/emptypb",
+        "@org_golang_google_protobuf//types/known/structpb",
+        "@org_golang_google_protobuf//types/known/timestamppb",
+    ],
+)
+
+alias(
+    name = "go_default_library",
+    actual = ":expr",
+    visibility = ["//visibility:public"],
+)

vendor/cel.dev/expr/.gitignore

@@ -0,0 +1,25 @@
+# Contributor Code of Conduct
+## Version 0.1.1 (adapted from 0.3b-angular)
+
+As contributors and maintainers of the Common Expression Language
+(CEL) project, we pledge to respect everyone who contributes by
+posting issues, updating documentation, submitting pull requests,
+providing feedback in comments, and any other activities.
+
+Communication through any of CEL's channels (GitHub, Gitter, IRC,
+mailing lists, Google+, Twitter, etc.) must be constructive and never
+resort to personal attacks, trolling, public or private harassment,
+insults, or other unprofessional conduct.
+
+We promise to extend courtesy and respect to everyone involved in this
+project regardless of gender, gender identity, sexual orientation,
+disability, age, race, ethnicity, religion, or level of experience. We
+expect anyone contributing to the project to do the same.
+
+If any member of the community violates this code of conduct, the
+maintainers of the CEL project may take action, removing issues,
+comments, and PRs or blocking accounts as deemed appropriate.
+
+If you are subject to or witness unacceptable behavior, or have any
+other concerns, please email us at
+[[email protected]](mailto:[email protected]).

vendor/cel.dev/expr/BUILD.bazel

@@ -0,0 +1,32 @@
+# How to Contribute
+
+We'd love to accept your patches and contributions to this project. There are a
+few guidelines you need to follow.
+
+## Contributor License Agreement
+
+Contributions to this project must be accompanied by a Contributor License
+Agreement. You (or your employer) retain the copyright to your contribution,
+this simply gives us permission to use and redistribute your contributions as
+part of the project. Head over to <https://cla.developers.google.com/> to see
+your current agreements on file or to sign a new one.
+
+You generally only need to submit a CLA once, so if you've already submitted one
+(even if it was for a different project), you probably don't need to do it
+again.
+
+## Code reviews
+
+All submissions, including submissions by project members, require review. We
+use GitHub pull requests for this purpose. Consult
+[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
+information on using pull requests.
+
+## What to expect from maintainers
+
+Expect maintainers to respond to new issues or pull requests within a week.
+For outstanding and ongoing issues and particularly for long-running
+pull requests, expect the maintainers to review within a week of a
+contributor asking for a new review. There is no commitment to resolution --
+merging or closing a pull request, or fixing or closing an issue -- because some
+issues will require more discussion than others.

vendor/cel.dev/expr/CODE_OF_CONDUCT.md

@@ -0,0 +1,43 @@
+# Project Governance
+
+This document defines the governance process for the CEL language. CEL is
+Google-developed, but openly governed. Major contributors to the CEL
+specification and its corresponding implementations constitute the CEL
+Language Council. New members may be added by a unanimous vote of the
+Council.
+
+The MAINTAINERS.md file lists the members of the CEL Language Council, and
+unofficially indicates the "areas of expertise" of each member with respect
+to the publicly available CEL repos.
+
+## Code Changes
+
+Code changes must follow the standard pull request (PR) model documented in the
+CONTRIBUTING.md for each CEL repo. All fixes and features must be reviewed by a
+maintainer. The maintainer reserves the right to request that any feature
+request (FR) or PR be reviewed by the language council.
+
+## Syntax and Semantic Changes
+
+Syntactic and semantic changes must be reviewed by the CEL Language Council.
+Maintainers may also request language council review at their discretion.
+
+The review process is as follows:
+
+- Create a Feature Request in the CEL-Spec repo. The feature description will
+  serve as an abstract for the detailed design document.
+- Co-develop a design document with the Language Council.
+- Once the proposer gives the design document approval, the document will be
+  linked to the FR in the CEL-Spec repo and opened for comments to members of
+  the [email protected].
+- The Language Council will review the design doc at the next council meeting
+  (once every three weeks) and the council decision included in the document.
+
+If the proposal is approved, the spec will be updated by a maintainer (if
+applicable) and a rationale will be included in the CEL-Spec wiki to ensure
+future developers may follow CEL's growth and direction over time.
+
+Approved proposals may be implemented by the proposer or by the maintainers as
+the parties see fit. At the discretion of the maintainer, changes from the
+approved design are permitted during implementation if they improve the user
+experience and clarity of the feature.

vendor/cel.dev/expr/CONTRIBUTING.md

@@ -187,7 +187,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2014 The Kubernetes Authors.
+   Copyright [yyyy] [name of copyright owner]
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

vendor/cel.dev/expr/GOVERNANCE.md

@@ -0,0 +1,13 @@
+# CEL Language Council
+
+| Name            | Company      | Area of Expertise |
+|-----------------|--------------|-------------------|
+| Alfred Fuller   | Facebook     | cel-cpp, cel-spec |
+| Jim Larson      | Google       | cel-go, cel-spec  |
+| Matthais Blume  | Google       | cel-spec          |
+| Tristan Swadell | Google       | cel-go, cel-spec  |
+
+## Emeritus
+
+* Sanjay Ghemawat (Google)
+* Wolfgang Grieskamp (Facebook)

vendor/k8s.io/gengo/LICENSE renamed to vendor/cel.dev/expr/LICENSE

@@ -0,0 +1,70 @@
+module(
+    name = "cel-spec",
+)
+
+bazel_dep(
+    name = "bazel_skylib",
+    version = "1.7.1",
+)
+bazel_dep(
+    name = "gazelle",
+    version = "0.36.0",
+    repo_name = "bazel_gazelle",
+)
+bazel_dep(
+    name = "googleapis",
+    version = "0.0.0-20240819-fe8ba054a",
+    repo_name = "com_google_googleapis",
+)
+bazel_dep(
+    name = "protobuf",
+    version = "26.0",
+    repo_name = "com_google_protobuf",
+)
+bazel_dep(
+    name = "rules_cc",
+    version = "0.0.9",
+)
+bazel_dep(
+    name = "rules_go",
+    version = "0.49.0",
+    repo_name = "io_bazel_rules_go",
+)
+bazel_dep(
+    name = "rules_java",
+    version = "7.6.5",
+)
+bazel_dep(
+    name = "rules_proto",
+    version = "6.0.0",
+)
+bazel_dep(
+    name = "rules_python",
+    version = "0.35.0",
+)
+
+### PYTHON ###
+python = use_extension("@rules_python//python/extensions:python.bzl", "python")
+python.toolchain(
+    ignore_root_user_error = True,
+    python_version = "3.11",
+)
+
+switched_rules = use_extension("@com_google_googleapis//:extensions.bzl", "switched_rules")
+switched_rules.use_languages(
+    cc = True,
+    go = True,
+    java = True,
+)
+use_repo(switched_rules, "com_google_googleapis_imports")
+
+go_sdk = use_extension("@io_bazel_rules_go//go:extensions.bzl", "go_sdk")
+go_sdk.download(version = "1.21.1")
+
+go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps")
+go_deps.from_file(go_mod = "//:go.mod")
+use_repo(
+    go_deps,
+    "org_golang_google_genproto_googleapis_rpc",
+    "org_golang_google_protobuf",
+)

vendor/cel.dev/expr/MAINTAINERS.md

@@ -0,0 +1,73 @@
+# Common Expression Language
+
+The Common Expression Language (CEL) implements common semantics for expression
+evaluation, enabling different applications to more easily interoperate.
+
+Key Applications
+
+*   Security policy: organizations have complex infrastructure and need common
+    tooling to reason about the system as a whole
+*   Protocols: expressions are a useful data type and require interoperability
+    across programming languages and platforms.
+
+
+Guiding philosophy:
+
+1.  Keep it small & fast.
+    *   CEL evaluates in linear time, is mutation free, and not Turing-complete.
+        This limitation is a feature of the language design, which allows the
+        implementation to evaluate orders of magnitude faster than equivalently
+        sandboxed JavaScript.
+2.  Make it extensible.
+    *   CEL is designed to be embedded in applications, and allows for
+        extensibility via its context which allows for functions and data to be
+        provided by the software that embeds it.
+3.  Developer-friendly.
+    *   The language is approachable to developers. The initial spec was based
+        on the experience of developing Firebase Rules and usability testing
+        many prior iterations.
+    *   The library itself and accompanying toolings should be easy to adopt by
+        teams that seek to integrate CEL into their platforms.
+
+The required components of a system that supports CEL are:
+
+*   The textual representation of an expression as written by a developer. It is
+    of similar syntax to expressions in C/C++/Java/JavaScript
+*   A representation of the program's abstract syntax tree (AST).
+*   A compiler library that converts the textual representation to the binary
+    representation. This can be done ahead of time (in the control plane) or
+    just before evaluation (in the data plane).
+*   A context containing one or more typed variables, often protobuf messages.
+    Most use-cases will use `attribute_context.proto`
+*   An evaluator library that takes the binary format in the context and
+    produces a result, usually a Boolean.
+
+For use cases which require persistence or cross-process communcation, it is
+highly recommended to serialize the type-checked expression as a protocol
+buffer. The CEL team will maintains canonical protocol buffers for ASTs and
+will keep these versions identical and wire-compatible in perpetuity:
+
+*  [CEL canonical](https://github.com/google/cel-spec/tree/master/proto/cel/expr)
+*  [CEL v1alpha1](https://github.com/googleapis/googleapis/tree/master/google/api/expr/v1alpha1)
+
+
+Example of boolean conditions and object construction:
+
+``` c
+// Condition
+account.balance >= transaction.withdrawal
+    || (account.overdraftProtection
+    && account.overdraftLimit >= transaction.withdrawal  - account.balance)
+
+// Object construction
+common.GeoPoint{ latitude: 10.0, longitude: -5.5 }
+```
+
+For more detail, see:
+
+*   [Introduction](doc/intro.md)
+*   [Language Definition](doc/langdef.md)
+
+Released under the [Apache License](LICENSE).
+
+Disclaimer: This is not an official Google product.