flagd-proxy HA setup

[xvzf]

Based on the behaviour observed and the fixed replica count of 1 (ref), I'm wondering if it makes to have two or more instances of the flagd-proxy running in combination with a PodDisruptionBudget.

I can work on this (either as a config option or extending the schema similar to what's currently discussed in https://github.com/open-feature/open-feature-operator/issues/524), but wanted to ask for feedback here first!

[toddbaert]

@xvzf I like this idea. I think maybe we should default to 2 instances. I think an additional config option makes sense, but I'm interested in the opinions of others... @odubajDT @Kavindu-Dodan @thisthat what do you think?

It seems https://github.com/open-feature/open-feature-operator/issues/524 is pretty stale, I'm going to close it.

[Kavindu-Dodan]

We could do this through environment variables dedicated to proxy [1]. And regarding the need for replicas, I assume this is to provide HA for your use case and I think this is a good overal improvement.

[1] - https://github.com/open-feature/open-feature-operator/blob/main/docs/flagd_proxy.md#configuration

[thisthat]

I think having HA for a central component like the proxy definitely makes sense 👍 I am wondering where we should allow this configuration 🤔 Currently, OFO creates the proxy as soon as it sees a FeatureFlagSource that has flagd-proxy as the provider. I think we should allow the three values to be configurable as EnvVar (with the Helm relative value entries): replica count, minAvailable, and maxUnavailable. This way, at startup OFO creates/updates the PodDisruptionBudget policy.

[xvzf]

I'll come up with a draft PR in the next days :)

[toddbaert]

Somebody mentioned this specific issue at KubeCon, so I guess you're right @xvzf