Automatic merge from submit-queue (batch tested with PRs 61378, 60915, 61499, 61507, 61478). 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>.
remove unused htpasswd
This file is not used anywhere.
Further more, this is an error in this file:
```
$ flake8 third_party/htpasswd/htpasswd.py --select=F
third_party/htpasswd/htpasswd.py:46:13: F821 undefined name 'time'
```
**Release note**:
```release-note
NONE
```
Fix kubernetes build scripts to work in case the source directory is in
a directory path which contains a space.
You can prepare such a directory like this:
$ mkdir '/tmp/test dir/'
$ cd '/tmp/test dir/'
$ git clone https://github.com/kubernetes/kubernetes.git
$ cd kubernetes
Then, without the fix:
$ KUBE_FASTBUILD=true KUBE_RELEASE_RUN_TESTS=n build/release.sh
cat: /tmp/test: No such file or directory
cat: dir/kubernetes/build/build-image/cross/VERSION: No such file or directory
cat: /tmp/test: No such file or directory
cat: dír/kubernetes/build/build-image/VERSION: No such file or directory
+++ [0307 18:10:33] Verifying Prerequisites....
cp: target '/tmp/test dir/kubernetes/_output/images/kube-build:build-7c7cd10a18--/Dockerfile' is not a directory
!!! [0307 18:10:33] Call tree:
!!! [0307 18:10:33] 1: build/release.sh:35
kube::build::build_image(...)
!!! Error in build/../build/common.sh:454
Error in build/../build/common.sh:454. '((i<3-1))' exited with status 1
Call stack:
1: build/../build/common.sh:454 kube::build::build_image(...)
2: build/release.sh:35 main(...)
Exiting with status 1
With the fix the compilation succeeds. The fix is done adding double
quotes to required places (and also just in case to other places where
shellcheck recommended adding them).
Note that this fix doesn't help with the official make-based build:
it's tricky to make makefiles work with targets with spaces in their
names.
This file is not used anywhere.
Further more, this is an error in this file:
```
$ flake8 third_party/htpasswd/htpasswd.py --select=F
third_party/htpasswd/htpasswd.py:46:13: F821 undefined name 'time'
```
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.
basically just:
* move all manifests into the new gce/manifests dir
* move limit-range into gce/addons/limit-range
* move abac jsonl into gce/manifests. this is gross but we will
hopefully be able to delete this config soon. it only exists to support
a deprecated feature.
* fix build, release, deploy to look for everything in its new home
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.
```
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>.
Introduce GCE-specific addons directory
**What this PR does / why we need it**:
GCE & GKE currently rely on the cluster bringup defined in the `cluster/gce` directory, but there isn't a good way of deploying GCE specific manifests. Currently the 2 approaches are, put it in `/cluster/addons`, which implies it should be generally useful (not GCE specific), or it is synthesized by one of the bash scripts in `cluster/gce`.
This PR introduces a straightforward way to have GCE-specific manifests deployed for GCE & GKE, without the need to pollute the general addon space.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#53032
**Special notes for your reviewer**:
**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
```
Automatic merge from submit-queue
Support arbitrary alphanumeric strings as prerelease identifiers
**What this PR does / why we need it**: this is basically an extension of #43642, but supports more general prerelease identifiers, per the spec at http://semver.org/#spec-item-9.
These regular expressions are still a bit more restrictive than the SemVer spec allows (we disallow hyphens, and we require the format `-foo.N` instead of arbitrary `-foo.X.bar.Y.bazZ`), but this should support our needs without changing too much more logic or breaking other assumptions.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 42379, 42668, 42876, 41473, 43260)
Silence error messages from the docker rmi call we expect to fail
**What this PR does / why we need it**: when we removed `docker tag -f` in #34361 we added a bunch of `docker rmi` calls to preserve behavior for older docker versions. That step is usually a no-op, however, and results in confusing messages like
```
Tagging docker image gcr.io/google_containers/kube-proxy:c8d0b2e7a06b451117a8ac58fc3bb3d3 as gcr.io/kubernetes-release-test/kube-proxy-amd64:v1.5.4
Error response from daemon: No such image: gcr.io/kubernetes-release-test/kube-proxy-amd64:v1.5.4
```
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#42665
**Special notes for your reviewer**: I could probably remove the `docker rmi` calls entirely, though I don't know if folks are still using docker < 1.10. (I think Jenkins still has 1.9.1.)
**Release note**:
```release-note
NONE
```
cc @jessfraz
This update includes significant refactoring. It moves almost all of the
logic into bash scripts, modeled after the `gci` cluster scripts.
The primary differences between the two are the following:
1. Use of the `/opt/kubernetes` directory over `/home/kubernetes`
2. Support for rkt as a runtime
3. No use of logrotate
4. No use of `/etc/default/`
5. No logic related to noexec mounts or gci-specific firewall-stuff
Tim Hockin