The "// import <path>" comment has been superseded by Go modules.
We don't have to remove them, but doing so has some advantages:
- They are used inconsistently, which is confusing.
- We can then also remove the (currently broken) hack/update-vanity-imports.sh.
- Last but not least, it would be a first step towards avoiding the k8s.io domain.
This commit was generated with
sed -i -e 's;^package \(.*\) // import.*;package \1;' $(git grep -l '^package.*// import' | grep -v 'vendor/')
Everything was included, except for
package labels // import k8s.io/kubernetes/pkg/util/labels
because that package is marked as "read-only".
Kubernetes-commit: 8a908e0c0bd96a3455edf7e3b5f5af90564e65b0
The canonical import for json-patch v4 is
gopkg.in/evanphx/json-patch.v4 (see
https://github.com/evanphx/json-patch/blob/master/README.md#get-it for
reference).
Using the v4-specific path should also reduce the risk of unwanted v5
upgrade attempts, because they won't be offered as automated upgrades
by dependency upgrade management tools, and they won't happen through
indirect dependencies (see
https://github.com/kubernetes/kubernetes/pull/120327 for context).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 5300466a5c8988b479a151ceb77f49dd00065c83
Fixes the argument order used when calling testing.NewUpdateSubresourceAction
within the fake scale client. This was causing the generated action to swap the values
of the Namespace and Subresource in the Action.
Kubernetes-commit: 34a446d812c423da7a306963f250f4002dac9be8
Clarifies that requesting no conversion is part of the codec factory, and
future refactors will make the codec factory less opionated about conversion.
Kubernetes-commit: 7f9dfe58f4cbe1e1b9e80f52addff70bac87bed4
note that we don't change the behaviour of kubectl.
For example it won't scale new resources. That's the end goal.
The first step is to retrofit existing code to use the generic scaler.
Kubernetes-commit: dd9de90b0ad1aa78c2a8dd7d5238d8f769ffe771
apps/v1betaX inadventertently contains its own variant of Scale. In
order to support scaling Deployments, ReplicaSets, etc, we need to support
these versions of Scale as well.
Kubernetes-commit: 2c9fc432947bedb2fffc12faf7fc0ee1d0ceffd9
This adds a new fake scale client (for use in testing) to match the
new polymorphic scale client.
Kubernetes-commit: f22bfcd65acafc75235665feac3b147f16e30998
This introduces a polymorphic scale client capable of operating against
scale subresources which return different group-versions of Scale. The
scale subresources may be in group-versions different than the scale
itself, so that we no longer need a copy of every scalable resource in
the extensions API group.
To discovery which Scale group-versions go to which subresources,
discovery is used.
The scale client maintains its own internal versions and conversions to
several external versions, with a "hub" version that's a copy of the
autoscaling internal version.
It currently supports the following group-versions for Scale subresources:
- extensions/v1beta1.Scale
- autoscaling/v1.Scale
Kubernetes-commit: d61a2d90372c301dd11088df8941acf2bb01c38c
