We end up with two deployments pointing to the new replica sets.

Hence it keeps getting scaled up and down.

So we need to remove all labels (for instance).

if there is a latest tag, it triggers a deployment but with a tag set as an empty string.

Bad parsing of latest which we should avoid anyway.

The correct behavior would be to log the fact that there is an image with 'latest' tag but not create a deployment.

when renaming the project ktune, this broke the build of course.

Fix the references and check the vendoring

the go client for k8s is now at:

https://github.com/kubernetes/client-go

fix imports, vendoring and calls in code

There is a nice project: skopeo:

https://github.com/projectatomic/skopeo

there might be some good things there to refactor dockerhub.go

need a Makefile...

We need to publish a docker image that contains ktune and can run "in" cluster.

write a deployment .yaml file in the source, like we did with https://github.com/skippbox/kubewatch

looking at docker images for creating canaries is one of the use cases.

We should refactor a bit to stub out other possible tuning scenarios (e.g setting container limits based on monitoring data from prometheus).

The choice of tuning mechanism might be set as ktune configuration options.

Currently, ktune creates a new deployment to create a canary pattern..

Thank whether we should just edit the existing deployment, which would create a new replica sets directly.

We could always rollback .

However, I am not convinced. We may want to create an actual new deployment.