feat!: Support Multiple Syncs

[james-milligan]

Signed-off-by: James Milligan james@omnant.co.uk

corresponding flagd changes here

This PR

• updates the openfeature.dev/featureflagconfiguration to allow for multiple syncs to be provided to the flagd sidecar, the annotation value is now a comma separated list with each value providing both the namespace and the CRD name separated with a /, if no namespace is provided it is assumed that the crd is in the same namespace as the deployment e.g. "end-to-end, test/end-to-end-2"
• introduces remote sync implementation

Related Issues

#251

Notes

Follow-up Tasks

How to test

• This is a breaking change and will not work with the existing flagd version, a build from this PR will be required to test

[codecov-commenter]

Codecov Report

Merging #256 (47d46c3) into main (9e55a4f) will decrease coverage by 5.72%.
The diff coverage is 49.03%.

@@            Coverage Diff             @@
##             main     #256      +/-   ##
==========================================
- Coverage   56.18%   50.46%   -5.73%     
==========================================
  Files           3        3              
  Lines         388      432      +44     
==========================================
  Hits          218      218              
- Misses        156      199      +43     
- Partials       14       15       +1     

Impacted Files	Coverage Δ
controllers/featureflagconfiguration_controller.go	0.00% <0.00%> (ø)
webhooks/pod_webhook.go	67.66% <49.51%> (-13.42%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[james-milligan]

converting to draft to solve versioning issues

[toddbaert]

is there a reason to go with a comma delimited string over a proper yaml array? Is it just for more backward compatibility? If so, maybe there's another way to achieve it?

Maybe we could add openfeature.dev/featureflagconfigurations (note the "s") which could be an array?

I think this would be backward compatible... is this a completely dumb suggestion? @james-milligan @skyerus @AlexsJones

EDIT: as mentioned by @james-milligan , annotations can only have string values.

[james-milligan]

is there a reason to go with a comma delimited string over a proper yaml array? Is it just for more backward compatibility? If so, maybe there's another way to achieve it?

Maybe we could add openfeature.dev/featureflagconfigurations (note the "s") which could be an array?

I think this would be backward compatible... is this a completely dumb suggestion? @james-milligan @skyerus @AlexsJones

Unfortunately the annotation values must be of type string - I agree an array would be far nicer!

[toddbaert]

is there a reason to go with a comma delimited string over a proper yaml array? Is it just for more backward compatibility? If so, maybe there's another way to achieve it?
Maybe we could add openfeature.dev/featureflagconfigurations (note the "s") which could be an array?
I think this would be backward compatible... is this a completely dumb suggestion? @james-milligan @skyerus @AlexsJones

Unfortunately the annotation values must be of type string - I agree an array would be far nicer!

welp, that explains that. 😅

[james-milligan]

Maybe we could add openfeature.dev/featureflagconfigurations (note the "s") which could be an array?

ill update the parsing to assume that the current requests namespace is to be used if none is defined, this will keep it backwards compatible (excluding the CRD changes required to enable the remote/http sync)

[james-milligan]

e2e tests will continue to fail until the corresponding PR in flagd is merged, but I have tested it locally

[AlexsJones]

Nice work young man.
Please make sure this doesn't break the demo/watchman

[james-milligan]

This PR is ready to merge following this release
open-feature/flagd#215