Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding kubeadm util fetch-ci-image [commit]? #101

Closed
luxas opened this issue Jan 2, 2017 · 8 comments
Closed

Consider adding kubeadm util fetch-ci-image [commit]? #101

luxas opened this issue Jan 2, 2017 · 8 comments

Comments

@luxas
Copy link
Member

luxas commented Jan 2, 2017

I just threw together a small script for myself for testing against k8s head:

#!/bin/bash

CI_COMMIT=${CI_COMMIT:-latest}
ARCH=${ARCH:-amd64}

if [[ ${ARCH} == "amd64" ]]; then
	ARCH_EXT=""
else
	ARCH_EXT="-${ARCH}"
fi

OLD_REGISTRY=${OLD_REGISTRY:-gcr.io/google_containers}
NEW_REGISTRY=${NEW_REGISTRY:-${OLD_REGISTRY}}

if [[ ${CI_COMMIT} == "latest" ]]; then
	CI_COMMIT=$(curl -sSL https://storage.googleapis.com/kubernetes-release-dev/ci-cross/latest.txt)
fi

CI_COMMIT_TAG=$(echo ${CI_COMMIT} | sed "s/+/-/")

echo "Using commit: ${CI_COMMIT}"
echo "Tagging to registry: ${NEW_REGISTRY}"

images=(
	kube-apiserver
	kube-scheduler
	kube-controller-manager
	kube-proxy
)

for image in ${images[@]}; do
	curl -sSL https://storage.googleapis.com/kubernetes-release-dev/ci-cross/${CI_COMMIT}/bin/linux/${ARCH}/${image}.tar | docker load
	image_tag=$(curl -sSL https://storage.googleapis.com/kubernetes-release-dev/ci-cross/${CI_COMMIT}/bin/linux/${ARCH}/${image}.md5)
	docker tag ${OLD_REGISTRY}/${image}${ARCH_EXT}:${image_tag} ${NEW_REGISTRY}/${image}-${ARCH}:${CI_COMMIT_TAG}
	docker rmi ${OLD_REGISTRY}/${image}${ARCH_EXT}:${image_tag}
	echo "Image created: ${NEW_REGISTRY}/${image}-${ARCH}:${CI_COMMIT_TAG}"
done

cat <<EOF
Now you can run:
	kubeadm init --use-kubernetes-version ${CI_COMMIT_TAG}
EOF

Should we provide this functionality through a kubeadm util command or it is out of scope?
This is a discussion thread.

On the other hand, this could be fixed with making the CI automatically push the images it's building to gcr.io/kubernetes-release-dev or something and make kubeadm understand --use-kubernetes-version ci/latest for example. What are you in favor of?
Quite many users have asked for this, so bringing it up here

@jbeda @mikedanese @roberthbailey @errordeveloper @lukemarsden @dgoodwin

@kad
Copy link
Member

kad commented Jan 2, 2017

I'd rather bring back support of ci/* from initial versions of --use-kubernetes-version, but that require pushing images to registry (and hopefully PR images too).

@mikedanese
Copy link
Member

This would be very useful for e2e testing but I somewhat agree with @kad, tighter integration with --version would be nice. @pipejakob

@luxas
Copy link
Member Author

luxas commented Jan 3, 2017

Basically, we only have to start pushing CI images to the gcr.io/kubernetes-release-dev repository for example.

ref: kubernetes/test-infra#1400

@luxas
Copy link
Member Author

luxas commented Jan 3, 2017

cc @ixdy @spxtr

@luxas
Copy link
Member Author

luxas commented Jan 3, 2017

(I do think the pushing the images automatically and having version support those images OOTB is a much better solution, just posted the alternative here)

@mikedanese
Copy link
Member

That also works.

@jbeda
Copy link

jbeda commented Jan 17, 2017

See also #34.

@luxas
Copy link
Member Author

luxas commented May 29, 2017

Closing in favor for #238 which will be the real solution

@luxas luxas closed this as completed May 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants