Stopping gitops beta run
As a user when I stop the sync by ending the process then all of my files on the local filesystem remain. However, the workloads on the cluster no longer remain. Why do I want this behavior? I wanted to set up and configure my cluster and run some experiments. Now that I am happy with the state I want to transition the cluster state to be driven by GitOps. I expect to see my workloads disappear from the cluster when I disconnect the run. However, I also expect to be able to commit my workloads to my git repository and once they are on the default branch I will then see them reappear on the cluster because they are now driven by the GitOps process.
I.e. the temporary source and automation that I saw created for me is no longer viewable on the cluster. At this point, I should be able to commit and push to git.
Acceptance Criteria
When I stop the gitops beta run process then
- The temporary bucket source is removed from the cluster which in return will remove all assets created by that source.
- The temporary kustomization is removed from the cluster along with it's source outlined in the step above.
- If we bootstrapped the cluster for the user then Flux should remain on the cluster and there should be a logical default for the user left in their local directory that will enable them to continue to use Flux via GitOps workflows. E.g. I would expect the traditional flux-system folder to be their as well as the
GitRepositorysource on the main branch andKustomizationfor the reconciliation loop. - If the Weave GitOps dashboard was installed that should not remain on the cluster, but the manifests should remain in the local directory so it will be installed once the user merges their PR to main.
- All manifests that were created in the file system that were synced with the bucket source referenced in step 1 will remain in the local working directory.
Out of Scope
- The user cannot specify an alternative branch, it will be set up for the "default" branch in the repository.
- The source and kustomization completing the reconciliation loop will be in a suspended state. We are not dealing with that in this story.
tech bits: we need to hook up SIGTERM and do the resource cleanup before the process ends.
Is that sufficient? If my internet goes wonky, then it'd stay forever.
Would we need to check for some kind of heartbeat on the server to decide if we want to turn it off or not? Is that possible?
Is that sufficient? If my internet goes wonky, then it'd stay forever.
that's something out of scope actually. It's normal behavior for everything like remote docker, or even ssh.
maybe we need to make gitops run more robust instead like also cleaning up the dangling resources next time it starts.
If no Flux installed yet, the Flux manifest would be installed to ./clusters/default/flux-system. There will be 3 files in that directory,
- gotk-components.yaml
- gotk-sync.yaml
- kustomization.yaml
(Actually, the above files would be generated by Flux's bootstrap command to make its behavior consistent with each version of Flux).
We then detect the remote URL of the current Git repo, and generate GitRepository and Kustomization.
Both files should be placed into
./clusters/default/gitops-run/.
So that they can be picked up by the Flux bootstrap next time.
Or maybe we would print out something like,
To continue, you can run the following command to bootstrap Flux.
$ flux bootstrap ...
🤔 I guess we could do that as a start. We could always pivot away from the message. @chanwit do you think it would be dynamic and have all of the fields they need filled out?
This is being done by an entire epic with GitOps Run 1.5 Bootstrapping.