search

bluek8s / kubedirector

Kubernetes Director (aka KubeDirector) for deploying and managing stateful applications on Kubernetes
Apache License 2.0
400 stars 90 forks source link

develop app CR versioning story #24

Open joel-bluedata opened 6 years ago

joel-bluedata commented 6 years ago

Issues like:

joel-bluedata commented 4 years ago

Related to issue #229.

The consensus at the moment seems to be that:

If we follow through on something like the approach described in issue #229, then an existing CR could be edited to replace it with a newer version of the same distroID, to allow live upgrade of any clusters referencing that CR.

The admin could instead create an entirely new CR (with a different name) instead of editing an existing CR. This would leave any existing clusters alone, and new clusters could choose which version of the app they want to instantiate.

In this scenario there's no built-in way for a KDCluster to express "latest version of this app". The client would have to look for app CRs that have the distroID of interest, examine their version properties, and choose the app CR that has the desired version.

joel-bluedata commented 2 years ago

Developing this as part of our live app upgrade work, so it is also reasonable to expect this for the 1.0 release.

joel-bluedata commented 2 years ago

A kdapp resource has a distro ID and a version. When it is deployed into K8s it also gains a name and a namespace.

If multiple kdapp resources (with different names and/or namespaces) have the same distro ID but different versions, they are considered to be multiple versions of the same app.

When a kdcluster launches, currently it selects a kdapp resource by name, with the "spec.app" property of the kdcluster. Typically this kdapp resource will be in the same namespace as the kdcluster, but it's also possible for the kdapp to live in the same namespace as the KD operator itself. The "appCatalog" property of the kdcluster spec can choose between these namespaces, as described on the wiki.

We should also extend the kdcluster spec to allow picking a kdapp by distroID and optionally by version. The rationale for this feature is that a kdcluster launcher cares less about what the name of the kdapp resource is and more about what its distroID is. I.e. I want to launch a jupyter-notebook app and I don't really care whether the relevant kdapp resource has been named "jupyter" or "nb" or "fishcakes". I may want to launch a specific version of jupyter-notebook or just "latest version".

(The old way of selecting a kdapp by name will still be supported.)

This behavior should extend to live-app-upgrade as well. If I want to upgrade a kdcluster, I should be able to specify some specific new version of the current app, or just "latest version please".

Note that the version property currently is just an arbitrary string value. To be selectable as "latest version" it needs to adhere to a semantic-versioning format. We need to decide whether we should enforce a semantic-versioning interpretation for live app upgrades: i.e. if a kdcluster requests changing from version X to Y, should we only allow that if Y is a string that evaluates to being a semantically newer version than X?

So: