[FEATURE] Remove dependency on open-feature-operator

[odubajDT]

Details

Currently flagd/core has a direct dependency of open-feature-operator. It would be sufficient to remove this dependency and instead use unstructured.Unstructured to fetch the custom resources from OFO API.

Acceptance Criteria

• remove OFO dependency in flagd/core
• adapt unit tests

[Kavindu-Dodan]

I assume the problem that comes with this dependency is e2e tests ? Otherwise dependency should make the CRD validation straightforward

[thisthat]

The dependency is on the K8s sync where an informer is registered to watch for changes on OFO CRs.
The issue is that OFO APIs and Operator are released together. OFO also has a dependency on FlagD. Finally, FlagD has a dependency on OFO APIs. This creates a problem when it comes to introducing new APIs and changes since you would need to release a version of OFO that works with the new APIs but injects a version of FlagD that cannot work with them.
I would rather have a new artifact with just the OFO APIs. This way we break the release cycle dependency while maintaining a proper version check.

[toddbaert]

The dependency is on the K8s sync where an informer is registered to watch for changes on OFO CRs. The issue is that OFO APIs and Operator are released together. OFO also has a dependency on FlagD. Finally, FlagD has a dependency on OFO APIs. This creates a problem when it comes to introducing new APIs and changes since you would need to release a version of OFO that works with the new APIs but injects a version of FlagD that cannot work with them. I would rather have a new artifact with just the OFO APIs. This way we break the release cycle dependency while maintaining a proper version check.

How might we best accomplish this? Would we release this as a separate artifact from the OFO repo? Or do it from an entirely different repo?

[thisthat]

@toddbaert inclusive or answer: "yes" 😝
more seriously, I would first look into having that as a separate release package instead of creating a new repo. Given our experience with release please and flagD, it looks like simple enough to give it a try. I will do a small PoC to have a feeling for how much complexity this would bring

[thisthat]

I prepared a PoC for OFO here: open-feature/open-feature-operator#541
Please let me know if this is something we can go through, I will also finish this poc

[toddbaert]

I prepared a PoC for OFO here: open-feature/open-feature-operator#541 Please let me know if this is something we can go through, I will also finish this poc

This is GREAT! I think with the addition of in-memory providers to the SDKs, and the work that @Kavindu-Dodan is doing in flagd and go-contribs, we will have no more dep cycles involving flagd.

cc @beeme1mr

[toddbaert]

@thisthat @Kavindu-Dodan I think with the API release separated, we can close this?

[thisthat]

Yes we can close this :)