Support for migration logic in installation (Job manager)
a-thaler opened this issue · comments
Description
In the current installer, we usually have migration logic written in a job being triggered by helm hooks. But:
- We don't want to rely on helm features (a simple "helm template - kubectl apply" should work as well)
- We don't want to provide an option for writing dirty shell scripts
- We want to force people taking care about a smart stimulous. Do not just rely on pre-upgrade hook trigger and execute long-running job always but really think about when to execute dependent on a cluster state. If the cluster is already migrated the code should perform a minimal number of operations and should not consume time and resources.
Goal: Provide a way in the new installer to cover migration logic which usually should be executed only at max once in the life of a cluster. The new way should be golang based so that you can have it tested
Criterias:
- there is a well-defined place to put my migration logic in golang source code
- There is a well-defined interface to be implemented and to register my hook in order to get trigger on any install/upgrade
- The interface provides me access to the current kubernetes client instance and the components which are about to be processed
- the logic will be triggered on any upgrade/install and the logic needs to decide if it should be executed or not (check component list and do lookups in the cluster to determine state, do not make it dependent on version but actual state)
- a Pre- and Post execution option probably is required
- There is a guide on how to mark your logic with a deprecation note to know when it should be removed
- the migration execution time should be logged to easily spot the code that consumes too much time (after the migration is done the next run should execute in no time).
Reasons
Migrations are simply required, see for example attached issue. Changing the size of a PV for a statefulSet requires custom actions.
Attachments
A comment on the upgrade scope:
We have two kinds of possible migration actions:
- generic, component-independent. These should be applied regardless of any components being upgraded
- specific for a single component only.
Generic migrations should be applied before upgrade starts.
Component-specifc migrations may be applied just before the component is upgraded.
This is important if we want to support a model where we just upgrade a set of Components (or a single component only).
If we assume we always upgrade entire Kyma, then all migrations may be applied together before upgrade starts.
But the interface design will have impact on our flexibility in the future, like single-component-upgrade scenario.
A comment about cleanup/uninstall
If we want a clean "uninstall", we should be also able to "undo" any cluster-wide changes introduced by the migration logic.
Perhaps we should consider an "uninstall" lifecycle phase in our interface. So that the developer has a chance to remove/unset anything Kyma-specific from the cluster.
But then, how easy it is to do it over multiple kyma-cli versions?
If we install Kyma using version 1.30, then upgrade through 1.31, 1.32 ... etc. up to 1.40, will kyma-cli v.1.40 be able to "undo" things from 1.31 ?
Documented Design for PoC (Draft):