* Drop WorkloadRef field and introduce SchedulingGroup field in Pod API
* Introduce v1alpha2 Workload and PodGroup APIs, drop v1alpha1 Workload API
Co-authored-by: yongruilin <yongrlin@outlook.com>
* Run hack/update-codegen.sh
* Adjust kube-scheduler code and integration tests to v1alpha2 API
* Drop v1alpha1 scheduling API group and run make update
---------
Co-authored-by: yongruilin <yongrlin@outlook.com>
Kubernetes-commit: 3f094dc228318b89f1fef313543b960e35ca6e3e
When a resource exists on the server, kubectl apply --dry-run=client
was outputting the unchanged server state instead of showing what
would result from applying the manifest.
Fix by computing the three-way merge patch (same as real apply) and
then applying it locally to the current server state.
Kubernetes-commit: aea05ad180edaffbb1f09b41b62d452779ed1da1
The package is unmaintained, and kubectl doesn't rely on the
functionality it provides on top of Golang errors (stack traces).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 54b2fad0330032ae1bbac990f93a3644aa8a12af
Removing this restrictions will allow us to use these commands with the
new resize subresource.
Kubernetes-commit: e1ca63489f2b788f893ab37a27242ce319e1eaf6
The contains-group-resources was an implementation error, we specified
contains-group-kinds in the KEP.
Because it is in alpha, we simply switch to the new annotation.
We will recognize the old annotation and migrate existing alpha
applysets, but support for this migration can be removed in beta/GA of
applyset.
Kubernetes-commit: 10caecb3b22cf93c7caa2ac70d40af9b550c0da2
To improve wall-clock speed, we run list operations in parallel. This
particularly helps when the round-trip time is high.
We issue requests as quickly as possible, kube-apiservers should all
have priority and fairness at this point and we don't want to
duplicate/fight that system.
Kubernetes-commit: 82eee59d0feb4b303e6ef78ebb7ec646a059f266
* Test for ApplySet with --dry-run=client|server
* Use the real format for ApplySet ID
* Incorporate feedback
* Adjustments from rebase
Kubernetes-commit: 6a31757f45693fec5ea4723bcb405ce4437e31ca
As we apply objects when using apply/prune v2, we want to be sure they
include the label that ties them back to the applyset they are part
of.
Co-Authored-By: Katrina Verey <katrina.verey@shopify.com>
Kubernetes-commit: ab058308401b35b4865424cfa43ed75a554af2a3
Changes in kubectl apply --prune to support k8s Inclusive Naming Initiative:
* Deprecated the --prune-whitelist flag.
* Deprecated the PruneWhitelist field on ApplyFlags struct.
* Removed PruneWhitelist field (not used anywhere) from ApplyOptions struct.
* Added --prune-allowlist flag.
* Added PruneAllowlist field on ApplyFlags struct.
* Added unit tests for prune with allowlist
This commit also fixes a bug where the command would fail if you specified
the sameGVK multiple times for --allow-whitelist. Now it only attempts to
prune the unique set of allowed GVKs.
Kubernetes-commit: f7ebf4d8852d4500f24100ca9a4ca665efc1fada
Currently `kubectl apply` determines correct patch type for given
GVKs by trying to register schema and if it succeeds, it uses
strategic-merge-patch.
But OpenAPI endpoint already stores which patch types are supported
by GVKs. This PR checks OpenAPI endpoint to retrieve patch type,
if OpenAPI is enabled. If it is not enabled, patch type determination
will be done as conventional registration method.
Kubernetes-commit: cddbb0c56397448ac0489f0473a26601c1feece8
