Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Vendor gazelle and kazel
Rather that relying on upstream git repos that can break, vendor it all. These are NOT head of tree, respectively - they are some backrev forms that were previously being used.
```release-note
NONE
```
In nested virutalized environments, the 1 second max-time is too
low. Just bumping up WAIT_FOR_URL_API_SERVER does not work unless
we bump up the max-time too. Let us just make it configurable like
so folks can customize to their environment.
Do not bother with pushd/popd construct -- there is no need to go back
to original directory in a subshell. Use "find --exec" instead of "find
| xargs" to handle special file names better.
This is brittle and really only intended to workaround the fact that
gazelle has moved out of the bazelbuild/rules_go repo to its own
repo. I would rather see this reverted once we move to the same
version of gazelle as used by kubernetes/test-infra
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Extract gnu-sed detection into a function
**What this PR does / why we need it**:
Moves gnu-sed detection into a reusable function across scripts (considering it's in multiple places).
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
When the verify scripts fail to install a component using `go get`
today, they silence output go `stderr` and cause the user to not get any
actionable feedback on failure.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Automatic merge from submit-queue (batch tested with PRs 43443, 46193, 49071, 47252)
Run the update-staging-godeps script inside a docker container
**What this PR does / why we need it**:
This PR moves the update-staging-godeps script to run inside a docker container.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#45757
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
/assign @ixdy @sttts
Automatic merge from submit-queue (batch tested with PRs 43443, 46193, 49071, 47252)
[Federation][Kubefed] Support reference document autogeneration for kubefed
This PR is needed to address the documentation issue https://github.com/kubernetes/kubernetes.github.io/issues/2888
Apart from the code auto generation have updated some descriptions for consistency.
**Special notes for your reviewer**:
@kubernetes/sig-federation-misc
cc @madhusudancs @csbell
**Release note**:
```NONE
```
hack/local-up-cluster.sh uses cfssl to generate certificates and
will exit it cfssl is not already installed. But other cluster-up
mechanisms (GCE) that generate certs just download cfssl if not
present. Make local-up-cluster.sh do that too.
Per Clayton's suggestion, move stuff from cluster/lib/util.sh to
hack/lib/util.sh. Also consolidate ensure-temp-dir and use the
hack/lib/util.sh implementation rather than cluster/common.sh.
Automatic merge from submit-queue
Don't try to run hack/verify-staging-* on dirty repository
When the repo is dirty after running all `update-*` scripts in `hack/update-all.sh`, the staging verify scripts still fail. This PR removes these from `hack/update-all.sh`. Instead give useful instructions or continue automatically with `hack/update-all-staging.sh`.
Automatic merge from submit-queue
Build release tars using bazel
**What this PR does / why we need it**: builds equivalents of the various kubernetes release tarballs, solely using bazel.
For example, you can now do
```console
$ make bazel-release
$ hack/e2e.go -v -up -test -down
```
**Special notes for your reviewer**: this is currently dependent on 3b29803eb5, which I have yet to turn into a pull request, since I'm still trying to figure out if this is the best approach.
Basically, the issue comes up with the way we generate the various server docker image tarfiles and load them on nodes:
* we `md5sum` the binary being encapsulated (e.g. kube-proxy) and save that to `$binary.docker_tag` in the server tarball
* we then build the docker image and tag using that md5sum (e.g. `gcr.io/google_containers/kube-proxy:$MD5SUM`)
* we `docker save` this image, which embeds the full tag in the `$binary.tar` file.
* on cluster startup, we `docker load` these tarballs, which are loaded with the tag that we'd created at build time. the nodes then use the `$binary.docker_tag` file to find the right image.
With the current bazel `docker_build` rule, the tag isn't saved in the docker image tar, so the node is unable to find the image after `docker load`ing it.
My changes to the rule save the tag in the docker image tar, though I don't know if there are subtle issues with it. (Maybe we want to only tag when `--stamp` is given?)
Also, the docker images produced by bazel have the timestamp set to the unix epoch, which is not great for debugging. Might be another thing to change with a `--stamp`.
Long story short, we probably need to follow up with bazel folks on the best way to solve this problem.
**Release note**:
```release-note
NONE
```
