Some questions after following the bootstrap approach

[hatzhang]

Hi all
I followed the bootstrap process, and it worked to some extent. And i have a few questions:

1. When i bootstrap to a clusters alreay been bootstraped, it will show some error ✗ cluster already bootstrapped to ./clusters/staging path. What does this mean? Is that mean a Kubernetes Cluster can only be managed by one fluxcd, or a git repo with flux-system's CRDs.
2. I am able to add HelmRepository and HelmRelease using flux cli, and it worked. But don't know if there is a way to sync back those to git repo. Or i had to use flux export to turn those into manefiest files and add them to git repo.
3. I bootstrapped a fluxcd into this K8s cluster. And using flux create source git to add another git repo which has some HelmRelease CRDs. But it seemed fluxcd won't create HR again those ymls. Do i have to define a kustomization to make this work?
4. I bootstrapped a fluxcd, and add another git source, but when i try to add a kustomization against the new git source using cli , it ended with some dns error failed to download artifact from http://source-controller.flux-system.svc.cluster.local./gitrepository/flux-system/secondrepo/4076bd6362b4a0b56d4b809acfc23b29984923c2.tar.gz, error: Get "http://source-controller.flux-system.svc.cluster.local./gitrepository/flux-system/secondrepo/4076bd6362b4a0b56d4b809acfc23b29984923c2.tar.gz": dial tcp 10.99.134.233:80: connect: connection refused

[YuhuaDeng]

I am experiencing the same issue
`Every 2.0s: flux get kustomizations usmifhmaas01p: Sat Feb 20 15:56:05 2021

NAME READY MESSAGE

                            REVISION                                        SUSPENDED

cluster-services False failed to download artifact from http://source-controller.flux-system.svc.cluster.local./gitrepository/flux-system/flux-system/debbba98a22564ce4aa982effcc597
b3f6b18150.tar.gz, error: Get "http://source-controller.flux-system.svc.cluster.local./gitrepository/flux-system/flux-system/debbba98a22564ce4aa982effcc597b3f6b18150.tar.gz": dial tcp 10.15
2.183.109:80: i/o timeout master/debbba98a22564ce4aa982effcc597b3f6b18150 False
flux-system False failed to download artifact from http://source-controller.flux-system.svc.cluster.local./gitrepository/flux-system/flux-system/debbba98a22564ce4aa982effcc597
b3f6b18150.tar.gz, error: Get "http://source-controller.flux-system.svc.cluster.local./gitrepository/flux-system/flux-system/debbba98a22564ce4aa982effcc597b3f6b18150.tar.gz": dial tcp 10.15
2.183.109:80: i/o timeout master/debbba98a22564ce4aa982effcc597b3f6b18150 False
`

[rgstephens]

It looks like flux stores this info in the namespace it creates.

In my case, I am still trying out flux so I delete the flux-system namespace and everything except two CRD instances is deleted.

flux uninstall --namespace=flux-system

[kingdonb]

The CRDs have finalizers, which are there for the purpose of allowing Flux to clean up after itself.

If you delete the namespace flux-system which houses controllers for managing resources before you delete the CRD, then there is no chance for Flux to clean up after itself. Since Flux v0.9 (I believe) there has been additional attention given to the flux uninstall command which is documented here, to make sure that this does not happen and the right order of operations is followed if you use it.

What version of Flux CLI are you using? The older versions did not handle it so well. If you reinstall (or bootstrap again) Flux, then use the uninstall command while the controllers are functioning, it should take care of this order of operations. Please make sure you are on at least Flux 0.10.0 which was the latest release as of the time of your post and was released last week. It adds yet another fix as noted below so this should be all resolved now.

[stefanprodan]

No need for reinstall, running flux uninstall --namespace=flux-system with the v0.10 CLI will cleanup any leftovers.

[rgstephens]

Yes, that was my mistake, deleting the namespace. Uninstall worked as advertised. Thanks.