Skip to content

Conversation

fgrzadkowski
Copy link
Contributor

This will release the following images:

gcr.io/google_containers/kube-apiserver-amd64            v1.2                581627bd855f        2 minutes ago        54.09 MB
gcr.io/google_containers/kube-controller-manager-amd64   v1.2                90ea7e237fd8        2 minutes ago        48.17 MB
gcr.io/google_containers/kube-proxy-amd64                v1.2                028858138a94        2 minutes ago        162.4 MB
gcr.io/google_containers/kube-scheduler-amd64            v1.2                75aae7f75086        2 minutes ago        33.5 MB
gcr.io/google_containers/hyperkube-amd64                 v1.2                b962b62aa778        3 minutes ago        297.1 MB

Fixes #11751

@ihmccreery @mikedanese @quinton-hoole

@k8s-github-robot
Copy link

Labelling this PR as size/M

@k8s-github-robot k8s-github-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Dec 23, 2015
@k8s-bot
Copy link

k8s-bot commented Dec 23, 2015

GCE e2e test build/test passed for commit 7cb6d74efff8ca3e27fdb47bd83c6381de26fa96.

@k8s-bot
Copy link

k8s-bot commented Dec 23, 2015

GCE e2e build/test failed for commit 3f939af292326db99f771bc39930a8f9d1b19ad6.

@fgrzadkowski
Copy link
Contributor Author

Last failure is a flake in test:

Kubernetes e2e suite.Deployment deployment should scale up and down in the right order

)

local platforms=(
"linux-amd64"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be just amd64? Or am I missing something here?
Because I think the docker images should be named gcr.io/google_containers/binary-arch e.g. gcr.io/google_containers/hyperkube-amd64 instead of gcr.io/google_containers/hyperkube-linux-amd64

But, maybe you want darwin support in the future 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial motivation was consistency with how we name our server .tar.gz files with a release. However keeping only architecture has the advantage of being shorter.

@zmerlynn Any preference?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another advantage with just the arch is consistency with hyperkube and some other images

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What other images? I wouldn't take hyperkube as an example yet. It's still more like an experiment..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK @brendandburns has pushed the pause, skydns, exechealthz and other addon images as experimental images (with the arch naming)

The thing is just that we have to keep it consistent. I am working on first-class ARM support and the naming here is quite important.

I think we should go with arch only naming, because docker runs natively only on linux for the time being. If we want to support darwin or windows in the future is another (probably long) discussion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that consistency is important. But as you can see it's not obvious with what we should be consistent :)

Indeed some images have been pushed with -arm suffix. I'll change the naming to just the arch.

BTW - I've noticed non-trivial ARM images cannot be build on amd64 machines. That means that we'll not be able to officially release those. How do you envision releasing ARM images?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fgrzadkowski I'm working on it.
And yes, it's possible to dynamically cross-compile ARM binaries on amd64 hosts.
It's even possible to build ARM docker images on amd64, like hyperkube for example.
Inspiration: https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/

I was so happy when I got this working: https://gist.github.com/luxas/e319b314f22b18243b1d
I have (locally) integrated this gist into kube-build and it worked even on ARMv6 (e.g. hyperkube as it is pushed now, only works on ARMv7)
So I'm gonna upload a PR with my work when it's ready.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. Good to know.

I changed docker images naming to follow hyperkube convention.

@mikedanese
Copy link
Member

Fyi, I want to include hack/lib in the release tar (see #19086). That would be a good place to share library code between build/ and cluster/ if you want to go with something more similar to the previous PR.

@k8s-bot
Copy link

k8s-bot commented Dec 29, 2015

GCE e2e test build/test passed for commit f46ed7ecc1827dc8a3408489e87c026ab68a214c.

@fgrzadkowski
Copy link
Contributor Author

@mikedanese To be hones I like the new approach more :)

@zmerlynn I have updated this PR to also build and push docker image for hyperkube

"kube-controller-manager"
"kube-scheduler"
"kube-proxy"
"hyperkube"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about kubelet? Just asking

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kubelet is not running in docker container yet (I'm working on it...)

@k8s-bot
Copy link

k8s-bot commented Dec 29, 2015

GCE e2e test build/test passed for commit b207cc80a40c2a8a98b55df26848b7631a235cd2.

@@ -13,6 +16,12 @@ TEMP_DIR:=$(shell mktemp -d)
all: build

build:
ifndef REGISTRY
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fgrzadkowski Same comment here probably as: #19177 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@k8s-bot
Copy link

k8s-bot commented Jan 5, 2016

GCE e2e test build/test passed for commit e7e8c5a.

@zmerlynn
Copy link
Member

zmerlynn commented Jan 8, 2016

@k8s-bot test this

@fgrzadkowski Sorry, I've been on holidays and sick. Looking soon.

@luxas
Copy link
Member

luxas commented Jan 8, 2016

This will be great to have merged 👍

@zmerlynn
Copy link
Member

zmerlynn commented Jan 8, 2016

The Travis failure is weird. Kicking forcibly.

@zmerlynn zmerlynn closed this Jan 8, 2016
@zmerlynn zmerlynn added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 8, 2016
@k8s-bot
Copy link

k8s-bot commented Jan 8, 2016

GCE e2e build/test failed for commit e7e8c5a.

@gmarek
Copy link
Contributor

gmarek commented Jan 11, 2016

#19467
@k8s-bot test this

@k8s-bot
Copy link

k8s-bot commented Jan 11, 2016

GCE e2e test build/test passed for commit e7e8c5a.

@bgrant0607
Copy link
Member

cc @david-mcmahon

@k8s-github-robot
Copy link

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

@k8s-bot
Copy link

k8s-bot commented Jan 12, 2016

GCE e2e test build/test passed for commit e7e8c5a.

@k8s-github-robot
Copy link

Automatic merge from submit-queue


for arch in "${archs[@]}"; do
for binary in "${binaries[@]}"; do
local docker_target="${KUBE_DOCKER_REGISTRY}/${binary}-${arch}:${KUBE_DOCKER_IMAGE_TAG}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fgrzadkowski @mikedanese @zmerlynn
This creates compability issues when it doesn't push hyperkube only, it just pushes hyperkube-arch...
I assume we need to support hyperkube only until all guides etc. are updated.

ikehz pushed a commit that referenced this pull request Jan 27, 2016
…-#19061-upstream-release-1.1

Automated cherry pick of #19061
ikehz pushed a commit that referenced this pull request Jan 27, 2016
ikehz pushed a commit that referenced this pull request Jan 27, 2016
…ry-pick-of-#19061-upstream-release-1.1

Revert "Automated cherry pick of #19061"
@ikehz ikehz mentioned this pull request Jan 28, 2016
2 tasks
shyamjvs pushed a commit to shyamjvs/kubernetes that referenced this pull request Dec 1, 2016
…ry-pick-of-#19061-upstream-release-1.1

Automated cherry pick of kubernetes#19061
shyamjvs pushed a commit to shyamjvs/kubernetes that referenced this pull request Dec 1, 2016
shyamjvs pushed a commit to shyamjvs/kubernetes that referenced this pull request Dec 1, 2016
…mated-cherry-pick-of-#19061-upstream-release-1.1

Revert "Automated cherry pick of kubernetes#19061"
shouhong pushed a commit to shouhong/kubernetes that referenced this pull request Feb 14, 2017
…ry-pick-of-#19061-upstream-release-1.1

Automated cherry pick of kubernetes#19061
shouhong pushed a commit to shouhong/kubernetes that referenced this pull request Feb 14, 2017
shouhong pushed a commit to shouhong/kubernetes that referenced this pull request Feb 14, 2017
…mated-cherry-pick-of-#19061-upstream-release-1.1

Revert "Automated cherry pick of kubernetes#19061"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm "Looks good to me", indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.