Introduce concept of update strategies

[stepanstipl]

Typical problem to solve is doing zero downtime update of running application, by replacing containers one by one. Kubernetes provide such mechanisms - ie. rolling-update for ReplicationControllers or apply/patch for Deployments other resources.

I would think about introducing concept of update strategy which would be optional property of resource and which would determine what update strategy will be used for given resource. Ie. default can be smth like replace, but then for RCs it can be rolling, for deployments and other resources apply.

 - name: rabbitmq
    file: rabbitmq-rc.yaml
    type: replicationcontroller
    sharded: yes
    update-strategy: rolling

I wanted to ask if anything like this is planned and/or what do you think about this, as I would be eventually interested to work on it. Cheers

[ant31]

Thanks for the proposal, it's something we really would like to add (#26 (closed by mistake)).

I planned to have a default strategy at the package level too, and then per resources, like for the expander: https://github.com/kubespray/kpm-packages/blob/master/coreos/etcdv3/manifest.jsonnet#L10

(note: Let me know if you want to work on it, some modification are coming soon with the integration of https://github.com/cn-app-registry/cnr-server )

[stepanstipl]

Hi @ant31, yep strategy at package level & per resource sounds reasonable.

And yep, I'm happy to work on that. To put this in context - I've just recently came across kpm and it looks really good, I really like the concept of channels, just the delete/add default makes it unusable in reality for us.

To start with - would you prefer to call the property this just strategy?

I guess the implementation part would be mainly in 'https://github.com/coreos/kpm/blob/master/kpm/platforms/kubernetes.py'?

There's couple of options for Kube - apply vs. patch mainly. I would think that starting with apply should be most beneficial and also still keeping the logic in kube, patching would require to do some diff on kpm side I believe and that would probably be more tricky. Also I'm not sure if you can use patch on all types of resources supported by kpm, any thoughts on that?

[ant31]

I really like the concept of channels, just the delete/add default makes it unusable in reality for us.

Can you elaborate and/or create an issue for this so we can discuss it ? The idea of channels is to do the following:

• kpm deploy repo/myapp:stable
• kpm deploy repo/myapp:beta

First we need a way to know the strategy to apply. I propose to use annotations like for protected: https://github.com/coreos/kpm/blob/master/kpm/platforms/kubernetes.py#L86

Yes, apply is the method we want I think.

Current detete if exists occurs here: https://github.com/coreos/kpm/blob/master/kpm/platforms/kubernetes.py#L119

To propagate the package level default to per resource (can be done on a second step) https://github.com/coreos/kpm/blob/master/kpm/jsonnet/lib/kpm.libjsonnet#L71

[stepanstipl]

@ant31 re. the channels - sorry it was confusing, what I meant that add/delete strategy for updates prevents us from using kpm, as we need to be able to do rolling updates (no downtime). Channels are good as they are I believe.

I'll try to look into implementing first version of this then, should be able to do it within next couple of days.

[stepanstipl]

Hi, I hoped I would have time to implement this, but moved to Helm on the way (https://github.com/kubernetes/helm), so unfortunately I won't be able spend time working on this.

[ant31]

@stepanstipl no problem, thank you to let us know.

I leave the issue open as I'm going to work on it.

[AntonioMeireles]

@ant31 any update on this on your side (curious) ?

[ant31]

@AntonioMeireles this going to be the default behavior: #142