weave-gitops
weave-gitops copied to clipboard
GitOps Run clean
As a user, I get things can go wrong because distributed computing is hard. Nevertheless, we always need to make sure things are tidy and that includes the usage of gitops run
. I would like to have a command that will let me clean up any hanging instances of gitops run
. This command should be able to target specific sessions on a cluster or to clean up all sessions.
Acceptance Criteria
- When I run the command
gitops remove run
(or some other relevant verb that is consistent with our other commands) then I should see an error stating I need to target a specific session. - When I run the command
gitops remove run <session-id>
then the code should go and find that session on the cluster and clean up the kustomization and bucket and end the process. - When I run the command
gitops remove run --all-sessions
then the code should go and wreck havoc on the cluster viciously eliminating all instances of gitops run. This should effectively put the cluster back in "gitops mode". - When I run the command
gitops remove run
in any form and there are no sessions on the cluster at that time I should inform the user that there was nothing to clean up. This will make them happy knowing that things were already tidy and it was silly of them to run the command. - When I run the command
gitops remove run --help
I get some nice helpful information about cleaning these up.
Keep definition of session aligned with #2907
The former was created by GitOps Run, the latter by Vcluster CLI.
❯ kubectl get statefulset -l app=vcluster -A
NAMESPACE NAME READY AGE
default run-dev-3bf7e0d6-dirty 1/1 2m55s
vcluster-dev dev 1/1 80s
❯ kubectl get statefulset -l app=vcluster -l "app.kubernetes.io/part-of"="gitops-run" -A
NAMESPACE NAME READY AGE
default run-dev-3bf7e0d6-dirty 1/1 3m20s
Update: handle namespaces the way it's handled by e.g. kubectl
& flux
- there's a --namespace/-n
flag to specify namespace, if that's not present then we default to default
. For later: add -A
flag to query across namespaces if the user has cluster-level role binding.