Instead of automatically upgrading a service, I’m wondering if the supervisor should expose a hook to let the user specify what the upgrade action should be. For example in a Kubernetes cluster, the supervisor should let the Kubernetes operator know that a service needs to be upgraded and the operator will perform the upgrade action.
What do you think the feasibility of making actions in the supervisor more pluggable @christophermaier @reset?
Theoretically possible… I’d want to know more details about the usecase, as well as potential non-Kubernetes usecases that might also be served by such a change, just to ensure we don’t try to overfit a solution.
This is interesting to me. I can imagine that for packages that store state, having a hook like this might make it possible to do programmatic upgrades between versions ? I imagine there are lots of usecases but checking my current version against the inbound version to determine whether or not there’s some kind of schema change that needs to happen or the like might be possible.
I think this is also a feature I’ve seen other folks ask for. But I can’t remember in what context I’ve seen it. Probably mostly Kubernetes.
In Kubernetes or containers in general, I thought it was better practice to just stand up a new set of containers with the new version and then destroy the old ones. I.E. immutable infrastructure.
Thats common practice to be sure, but a lot of those common practices come from the way the available tools CAN operate sanely. Even if the k8s community doesnt latch on to this one, I still think it will be valuable for folks working more in VMs and bare metal.
If we are talking about bare metal, I’m definitely interested in this hook. The things you mentioned @eeyun are very useful actions prior to shutting down the action service and then upgrading to the next version. And then what would be nice is if once you do the upgrade and it fails health check, then the supervisor should revert the upgrade.