If a staging repo has .gitattributes files containing the `export-subst`
attribute ([example](b6c06a95d7/staging/src/k8s.io/client-go/pkg/version/.gitattributes)), then git expands the specified placeholders
when git archive is used.
When a published repo is downloaded from GitHub, GitHub does a
"git archive" under the hood. This means that the placeholders get
replaced by their relevant values. This type of "git archive"
application sometimes leads to undesired values. See the example below.
- In client-go, [line 59 in `pkg/version/base.go`](b6c06a95d7/staging/src/k8s.io/client-go/pkg/version/base.go (L59))
is expanded on a git archive. This line is needed as a fallback to
inject k8s version info for client-go when this info is not provided
via ldflags during builds.
- However, when k/client-go is vendored, the line gets expanded to _the
commit of the project vendoring client-go_ -- which is not helpful at
all! This also means that the vendored client-go will now contain
different (expanded) commit shas for different projects.
- To ensure reproducibility of source, this commit helps remove
the .gitattributes files before publishing the staging repos.
Additionally, when client-go is used as a library, we don't care about
the line being expanded to inject version info so it is also safe to
remove these files.
When tests attempt to validate behavior in the case that a client asks
for a resource version that is "too large" for the underlying storage,
the previous implementation would simply add 1 to the latest revision
seen. This is only appropriate for storage backends that
a) provide a continuous monotonic logical clock
b) have no other events occurring while the test runs
For instance, when using a singe etcd backend as a shared fixture for
these tests, adding 1 to a previously-seen revision is not suffcient to
ensure that the resulting revision is "too large". By instead using the
largest possible integer value, we can be certain of this.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
When using a legacy cloud provider, if kubelet is passed a node address
in --node-ip it will use this address in preference out the the
addresses by the cloud provider.
When using an external cloud provider, kubelet will annotate the Node
with the first --node-ip for use by the cloud provider. The cloud
provider validates this annotation but does not otherwise use it,
meaning that --node-ip has no effect.
This change moves the node address filtering code from kubelet to
component-helpers and updates both kubelet and cloud-provider to use it.
There is no functional change to kubelet, but cloud-provider now honours
kubelet's --node-ip.
