feat: add flagd sidecar resources attribute

[L3o-pold]

This PR

• adds resources attribute for FlagSourceConfiguration CRD to configure flagd sidecar resources

Related Issues

Fixes #511

Notes

Follow-up Tasks

How to test

[codecov]

Codecov Report

Merging #514 (d88e783) into main (31d8d5a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #514      +/-   ##
==========================================
+ Coverage   82.70%   82.78%   +0.07%     
==========================================
  Files          22       22              
  Lines        1417     1423       +6     
==========================================
+ Hits         1172     1178       +6     
  Misses        207      207              
  Partials       38       38              

Files Changed	Coverage Δ
...pis/core/v1alpha1/flagsourceconfiguration_types.go	97.09% <ø> (ø)
...is/core/v1alpha2/featureflagconfiguration_types.go	50.00% <ø> (ø)
...pis/core/v1alpha3/flagsourceconfiguration_types.go	100.00% <ø> (ø)
controllers/common/flagd-injector.go	91.04% <100.00%> (+0.15%)	⬆️

Flag	Coverage Δ
unit-tests	82.78% <100.00%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[Kavindu-Dodan]

Thank you again for your contribution.

We already have the ability to configure flagd resource limits. But this is done through operator startup parameters ^{1 2}. However, these configurations seems to be not well documented and difficult to manipulate the K8s descriptors. Hence, I see the proposed approach through this PR to superior.

However, I think we can still have default resource requests/limits defined through current configurations and later override them through proposed change. @L3o-pold if you have time, you can write tests to cover this overriding behavior

cc - @toddbaert & @thisthat appreciate input

Footnotes

1. https://github.com/open-feature/open-feature-operator/blob/main/main.go#L268-L275 ↩

2. https://github.com/open-feature/open-feature-operator/blob/e74006872ebbc6595332a3722657f64e34ef1f29/controllers/common/flagd-injector.go#L346 ↩

[L3o-pold]

@Kavindu-Dodan My current PR continues to use resources limits defined on the operator level but allow custom resources limits (override).

[beeme1mr]

Hey @L3o-pold, could you please update the FlagSourceConfiguration docs with an example?

[Kavindu-Dodan]

@Kavindu-Dodan My current PR continues to use resources limits defined on the operator level but allow custom resources limits (override).

Yup, thank you for noticing this

+1 for @beeme1mr's point on doc update

[Kavindu-Dodan]

Approving

Let's wait for #513 and rebase before the merge

[Kavindu-Dodan]

@L3o-pold could you please rebase and resolve conflicts that comes from #513 ? I will get this through within the day

[thisthat]

Thank you again for your contribution.

We already have the ability to configure flagd resource limits. But this is done through operator startup parameters 1 2. However, these configurations seems to be not well documented and difficult to manipulate the K8s descriptors. Hence, I see the proposed approach through this PR to superior.

However, I think we can still have default resource requests/limits defined through current configurations and later override them through proposed change. @L3o-pold if you have time, you can write tests to cover this overriding behavior

cc - @toddbaert & @thisthat appreciate input

Footnotes

1. main/main.go#L268-L275 ↩
2. e740068/controllers/common/flagd-injector.go#L346 ↩

I agree with your suggestion @Kavindu-Dodan 👍
Unrelated to this PR, I noticed that the FlagSourceConfigurationSpec allows configuring the image to inject. I would suggest removing this property from such a configuration CRD since it could be abused to inject arbitrary images and could be a security problem. I see the need to allow using a different registry (e.g., in air-gapped envs), but I would rather keep it only as a startup parameter.

[Kavindu-Dodan]

@thisthat thank you for noticing this. I think we can follow-up on this improvement as well as the test scenario I described later on

I will go ahead with the merging this PR

[Kavindu-Dodan]

Thank you again for your contribution.
We already have the ability to configure flagd resource limits. But this is done through operator startup parameters 1 2. However, these configurations seems to be not well documented and difficult to manipulate the K8s descriptors. Hence, I see the proposed approach through this PR to superior.
However, I think we can still have default resource requests/limits defined through current configurations and later override them through proposed change. @L3o-pold if you have time, you can write tests to cover this overriding behavior
cc - @toddbaert & @thisthat appreciate input

Footnotes

1. main/main.go#L268-L275 ↩
2. e740068/controllers/common/flagd-injector.go#L346 ↩

I agree with your suggestion @Kavindu-Dodan 👍 Unrelated to this PR, I noticed that the FlagSourceConfigurationSpec allows configuring the image to inject. I would suggest removing this property from such a configuration CRD since it could be abused to inject arbitrary images and could be a security problem. I see the need to allow using a different registry (e.g., in air-gapped envs), but I would rather keep it only as a startup parameter.

Created a follow-up for this #517