KusionStack
feat: support release rollback
What would you like to be added?
support release rollback, i.e. kusion apply with specified release
Why is this needed?
rollback to the last success release quickly
kusion release rollback --revision=[num] kusion rollback --revision=[num]
Which of these two methods do you think is better?
kusion release rollback --revision=[num] kusion rollback --revision=[num]
Which of these two methods do you think is better?
I think out of these two, kusion release rollback is better, since the user would typically do the following together:
-
kusion release list, shows all release revisions under a stack -
kusion release show --revision, selects a particular revision to look into -
kusion release rollback, use the selected revision to rollback (effectively roll forward because it involves a new apply)
kusion release rollback is more intuitive in this case.
Another option may be simply supporting kusion apply with an additional flag --release-revision xxx, with the benefit of one less concept.
cc @liu-hm19
I thought about a few points and wanted to discuss it. What is our positioning of the rollback behavior? Is it different from the normal apply? Will a new release version be generated? Or is it just a rollback version, parallel to the release version? role. We must think about these designs in advance before we can proceed with code development.
@riven-blade Well, what we expect for the kusion release rollback sub-command is to conveniently help users roll back to a specific succeeded Release version. In particular, the sub-command will use the Spec of the specified succeeded Release. Therefore, from the perspective of execution, it should be similar to the command of kusion apply --spec-file [/path/to/spec.yaml] and will result in the creation of a new revision.
If you have any different thoughts on the kusion release rollback sub-command, feel free to share in the comments at any time!
For reference implementation, I would suggest you guys take a look at helm rollback, helm provides similar functionality to rollback release to a previous revision, code snippet can be found here. cc @riven-blade @liu-hm19
I looked through the code logic of helm rollback. It found the previousRelease version and generated a targetRelease based on it, and then changed currentRelease -> targetRelease. In our scenario, our apply deployment will have some parameters - -yes, detail, diff, etc., are they needed in rollback?
@riven-blade I think during the execution of kusion release rollback, it is still necessary to retain the flags related to previewing the apply diffs. And I'll take another close look at how helm's rollback is implemented. Could you provide a brief implementation design based on our discussion?
Okay, I'm doing it now. I'll make a first version first. In the design of helm, I understand that it has almost no terminal interaction. We have more terminal interaction in apply. I took a rough look at its rollback and packaged the old version release into a target release, deploy.