This will resolve the kubernetes-anywhere e2e test.
In commit: https://github.com/kubernetes/kubernetes/pull/71540
I bumped the required version of kubernetes-cni to 0.6.0 but didn't
start packaging it. This resolve that.
Signed-off-by: Duffie Cooley <dcooley@heptio.com>
First version of this was only standalone, now the code is being
vendored by anyone who wants to use it. So the standalone binary and
container are no longer useful.
Change-Id: Ib9369de66b4ecb3451f73ba2a252526d6615b96f
This is the 2nd attempt. The previous was reverted while we figured out
the regional mirrors (oops).
New plan: k8s.gcr.io is a read-only facade that auto-detects your source
region (us, eu, or asia for now) and pulls from the closest. To publish
an image, push k8s-staging.gcr.io and it will be synced to the regionals
automatically (similar to today). For now the staging is an alias to
gcr.io/google_containers (the legacy URL).
When we move off of google-owned projects (working on it), then we just
do a one-time sync, and change the google-internal config, and nobody
outside should notice.
We can, in parallel, change the auto-sync into a manual sync - send a PR
to "promote" something from staging, and a bot activates it. Nice and
visible, easy to keep track of.
Automatic merge from submit-queue (batch tested with PRs 54773, 52523, 47497, 55356, 49429). 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>.
don't check in mounter binary
```release-note
GCI mounter is moved from the manifests tarball to the server tarball.
```
- kubernetes-cni package now has proper version (0.5.1)
- Synchronize post-1.8 version of 10-kubeadm.conf file from release
repository.
- Fix dependencies
- Improve descriptions in produced packages
**What this PR does / why we need it**:
Visibility rules allow dependency control. The rules currently in
place make all targets public, to override the default state of
private. This PR removes public visibility from kubectl code. It
uses specially named pacakge groups to identify "bad" dependencies on
kubectl code for later refactoring or removal.
**Which issue this PR fixes**
First in a series of PRs to address kubernetes/community#598
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Use munged semantic version for side-loaded docker tag
**What this PR does / why we need it**: rather than using the md5sum of the dockerized binary for each side-loaded docker image, use the semantic version (with `+`s replaced with `_`s) for the side-loaded docker images.
The use of the md5sum for the docker tag dates to #6326 2 years ago. I'm not sure why that was chosen, short of it being fairly unique.
My main motivation for changing this is that it makes building the docker images using Bazel's docker rules easier, since the semantic version doesn't depend on the build output.
An added benefit is that the list of images on a running kubernetes cluster is also more straightfoward; rather than a list of opaque, meaningless hexadecimal strings, you get something that indicates the provenance of the image. It'd also be clearer that all of the images came from the same build.
I was able to start a cluster with this change on GCE using both `make quick-release` and `make bazel-release`.
Note that this change has no effect on the tag that's pushed to gcr.io during releases; that's still controlled via `KUBE_IMAGE_DOCKER_TAG`, though we may want to merge this functionality at some point.
@kubernetes/sig-node-pr-reviews is there any reason to stick with using the md5sum strategy? @dchen1107 do you remember why we went with md5sums originally?
cc @spxtr @mikedanese
**Release note**:
```release-note
```
Jeff Grafton