Kubernetes operator for combining per-kubernets-namespace configs into main config

[devnev]

I'm only just looking at flipt and thinking about how it could work. Looking at it from a GitOps perspective, it would be great for each application to be able to deploy its flags to its own namespace, and flipt end up with the combined flags. One way to achieve this would be with an operator that reads configmaps (based on selectors in CRDs), combines them with the correct namespace, and writes the result into the main flipt configmap.

[GeorgeMac]

Thanks for opening up this discussion @devnev !

We've actually long considered going a step further and letting k8s and a set of CRDs be a source of truth itself. (I've dropped the idea around a couple of times here and here in the past.
Where we implement a backend for Flipt that knows how to fetch these resources directly from the k8s API, parse those and build its evaluation snapshots, much in the same way as our Git / OCI / Object store backends do today. Effectively, making Flipt like a passive operator itself. Then users could simply apply Flag and Segment k8s resources and then Flipt would read those directly.

Focussing more on your suggestion there: I am just trying to understand a bit better what you mean by each application deploying their own flags and those being combined back up into Flipt itself. Usually, Flipt is the source of truth for all namespaces and flag state goes from Flipt to your applications, but my interpretation what you're describing is the opposite? Could you talk a bit more about what you're imagining there / correct me if I am misinterpretting (very likely haha).

[devnev]

Adressing the confusion first, I think that may have just been bad wording on my part. I meant that application developers (not the application itself) would deploy a CR with their flag values (alongside their application, in their namespace), which would be ingested into Flipt somehow. I think thats pretty much what you were describing too.

On the how, as I'd never written an operator before and this seemed like a fairly well-contained problem, I've prototyped up an operator that ultimately updates a ConfigMap with entries that could be used by the Flipt local backend. The backend would have to be configured to read all yml files in a mounted directory as configmap keys can't have path separators. Tests indicates it works and does something somewhat resonable, with a few issues that need ironing out.

[GeorgeMac]

I think I see now! Your goal is to still have a single addressable Flipt in a k8s cluster, where you can get an overview across namespaces, but where you organize and push the flipt namespaces to matching k8s namespaces and something slurps them up into that single Flipt 👌 Nice.

[devnev]

Indeed! Flipt would be set up by devops/infra/platform as a cluster service, with application developers only responsible for pushing their flag configuration and making their application consume results from the flipt service.

Another potential benefit I see (but haven't entirely thought through) is for per-PR namespaces in development clusters: changes to the application or flags would be deployed to the PR namespace (in kubernetes and flipt) without conflicting with other deployments. This also assumes a central flipt instance for the cluster.

If you want to see what I've got so far, take a look at https://github.com/devnev/flipt-features-operator - particularly of interested are maybe the types and the controller