Stefan Prodan

You can do this with Flux and Kustomize. Connect Flux to the private repo and in the private repo kustomization use remote bases pointing to your public repo: ```yaml bases:...

@aidun I would start with Flux, the helm operator should use the [SSH key generated by Flux](https://github.com/fluxcd/helm-operator/tree/master/chart/helm-operator#use-fluxs-git-deploy-key) so users don't have to add two deployment keys to the same repo.

Yes that's how Flux works by default.

Yes sharing the same cache is encouraged, the multi-tenancy does it here https://github.com/fluxcd/multi-tenancy/blob/master/cluster/team1/flux-patch.yaml#L12

Instead of import/export I would copy the SealedSecrets master key and do the whole bootstrap as it were a fresh install.

If OFC is GitOps you should't have to import/export anything expect for the private key.

To summarise the discussion on Slack: 1. Get the private key from the old cluster: `kubectl -n openfaas get secret sealed-secrets-key --export -oyaml > sealed-secrets-key.yaml` 2. Apply the private key...

Has anyone tried using Swagger to generate the API clients?

We already cover the node selector via stack constraints. PS. I think this issue should be moved to faas-netes since it's Kubernetes specific.

@benhosmer we require commit signoff, see https://github.com/fluxcd/flagger/pull/847/checks?check_run_id=2057997095