opened
paulfantom
username_0
<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://git.k8s.io/community/contributors/guide/pull-requests.md#the-pull-request-submit-process and developer guide https://git.k8s.io/community/contributors/devel/development.md#development-guide
2. If you want *faster* PR reviews, read how: https://git.k8s.io/community/contributors/guide/pull-requests.md#best-practices-for-faster-reviews
3. Follow the instructions for writing a release note: https://git.k8s.io/community/contributors/guide/pull-requests.md#write-release-notes-if-needed
4. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests
-->

**What this PR does / why we need it**:
- finalizing support for creating multi-arch images (Makefile already had some targets to build images for multiple architectures)
- adding support for creating a container manifest joining images into one
- fixing propagation of ARCH variable in `kube-state-metrics` target
- removed the containerized build process as there is no benefit of it when using go modules.

Tested by running:
```
make release-images REGISTRY=quay.io/username_0 TAG=$(git rev-parse --short HEAD)
```
Output can be seen in https://quay.io/repository/username_0/kube-state-metrics?tab=tags

Images validated on ARMv7 and AMD64 systems.

**NOTE**: This changes how images are published to quay.io. After merging, publishing images is done with `make release-images`. Added info about it in RELEASE.md

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes #1037
add support for building multi-CPU architecture images
issue
created
brancz
username_1
There is some work on publishing the images to k8s.gcr.io automatically, at that point we will probably no longer support the quay repo. I'm not sure how much work we should put into it. I'm fine with this, but be aware that it might disappear soon, and I don't know if the auto publishing workflow will support multi-arch.
comment
created
lilic
username_2
Not true, we will still publish the coreos images, no?
comment
created
paulfantom
username_0
/hold

Apparently docker on [travis has permissions problems](https://travis-ci.org/github/coreos/prometheus-operator/jobs/680948725#L547) when trying to create manifests.
comment
created
paulfantom
username_0
/unhold

moved to use `manifest-tool` tool instead of experimental docker feature to solve travis issue with docker permissions. Also simplifies Makefile a bit.
comment
created
tariq1890
username_3
Thanks for the PR @username_0 :). Provided some review comments
comment
created
mrueg
username_4
@username_3 @username_0 since I'm using kube-state-metrics on arm64, I would love to see this change in as it will simplifying deployment a lot. Anything I can help out with here to move it forward?
comment
created
paulfantom
username_0
@username_4 AFAIK right now kube-state-metrics is moving container builds to gcr (https://github.com/kubernetes/kube-state-metrics/pull/1155). After that move is done I don't this PR is necessary anymore (definitely not in this form).

Since right now I don't have time or desire to investigate this issue again, I am closing it.
comment