Closed stepanstipl closed 7 years ago
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 )
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?
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
@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.
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.
@stepanstipl no problem, thank you to let us know.
I leave the issue open as I'm going to work on it.
@ant31 any update on this on your side (curious) ?
@AntonioMeireles this going to be the default behavior: #142
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 berolling
, for deployments and other resourcesapply
.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