Run Helm Operator as a Flux sidecar

[stefanprodan]

Running the Helm Operator as a Flux sidecar would allows us to:

• remove the redundant Git sync from the Helm Operator
• reduce the scope of Helm Operator to CR -> Tiller operations only
• easier to deploy the Git repo config since only Flux will deal with Git syncs and auth
• use the same service account and RBAC

[errordeveloper]

To me, this sounds like the right thing to do, but I wonder why we've separated things in the first place...

[rossedman]

@stefanprodan @errordeveloper I think this makes a lot of sense. There are two different implementations of git sync right now between flux and helm operator. Redundant code could be deprecated or synced to shared hostDir.

[squaremo]

remove the redundant Git sync from the Helm Operator

There's no redundant git sync, or if there is, it's a mistake. The repo that the Helm operator needs to look at contains the charts, and that is logically distinct from the config repo (and can be practically distinct as well).

reduce the scope of Helm Operator to CR -> Tiller operations only

What do you suppose its scope is now?

easier to deploy the Git repo config since only Flux will deal with Git syncs and auth

As above, the Helm operator needs to monitor the charts repo.

use the same service account and RBAC

Sure, although I don't think the Helm operator needs the same, broad permissions (Helm escalates those for us!).

[rossedman]

@squaremo At the time I made my comment there was two different implementations of cloning from git in the codebase. I think that is what was being referred too.

[squaremo]

At the time I made my comment there was two different implementations of cloning from git in the codebase.

Ah right, yes. There still are two implementations, and needn't be.
Sharing the code is a separate matter to whether the containers run in the same pod, though.