feat: Add labels and annotations to pods.

[cpitstick-latai]

Currently, there is only one deployment, so avoid premature optimization by making these global (and follow the same pattern for imagePullSecrets)

Requires more aggressive usage of the strip-kustomize-helm.sh script because we have to preserve existing annotations and labels from the config/manager directory.

Notes

I chose to use maps.Copy which requires an upgrade in some of the golang dependencies. This function was made standard in Golang 1.21, which is the version the operator currently uses, so I don't foresee issues here.

Testing

There are 3 use-cases that matter here:

• Sidecar injection
• FlagD standalone
• FlagD proxy.

Label injection should happen only on the last two. Though I haven't tested those. I verified that this works on an EKS 1.27 cluster with a Calico CNI and verified sidecar injection doesn't break.

[toddbaert]

I'll give this and your other PRs a test tomorrow.

[toddbaert]

Hey @cpitstick-latai this is a great start! I was able to easily get the annotations/labels working locally after running make helm-release and setting some in my values.yaml. I think I see 2 issues:

• NOT passing any values seems to break the install. It's not immediately obvious to me why, since your defaults seem correct. In any case, I see:

helm upgrade --install open-feature-operator  /home/todd/git/open-feature-operator/charts/open-feature-operator-v0.6.1.tgz  
Release "open-feature-operator" does not exist. Installing it now.
Error: YAML parse error on open-feature-operator/templates/apps_v1_deployment_open-feature-operator-controller-manager.yaml: error converting YAML to JSON: yaml: line 16: did not find expected key

• This PR doesn't deal with the runtime pods created by the operator. I think the annotations/labels should be added there as well, similar to how we added imagePullSecret there. See feat: Add image pull secrets #655 and fix: handle multiple imagePullSecrets #666

[thisthat]

Hey @cpitstick-latai this is a great start! I was able to easily get the annotations/labels working locally after running make helm-release and setting some in my values.yaml. I think I see 2 issues:

• NOT passing any values seems to break the install. It's not immediately obvious to me why, since your defaults seem correct. In any case, I see:

helm upgrade --install open-feature-operator  /home/todd/git/open-feature-operator/charts/open-feature-operator-v0.6.1.tgz  
Release "open-feature-operator" does not exist. Installing it now.
Error: YAML parse error on open-feature-operator/templates/apps_v1_deployment_open-feature-operator-controller-manager.yaml: error converting YAML to JSON: yaml: line 16: did not find expected key

• This PR doesn't deal with the runtime pods created by the operator. I think the annotations/labels should be added there as well, similar to how we added imagePullSecret there. See feat: add image pull secrets #655 and fix: handle multiple imagePullSecrets #666

This sounds that we need to implement a CI action for testing the Helm installation in the e2e tests 🤔

[cpitstick-latai]

I'm working on addressing the issues you've found.

As to the e2e helm test, that feels out of scope for this PR. HOWEVER, we should create an issue for it.

[cpitstick-latai]

I think I fixed the issue where empty dictionaries {} break.

Thinking about how to implement the runtime pod issue.

[codecov]

Codecov Report

Attention: Patch coverage is 83.33333% with 5 lines in your changes missing coverage. Please review.

Project coverage is 86.63%. Comparing base (499661e) to head (344ba68).
Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #681      +/-   ##
==========================================
+ Coverage   86.51%   86.63%   +0.11%     
==========================================
  Files          19       19              
  Lines        1587     1601      +14     
==========================================
+ Hits         1373     1387      +14     
  Misses        173      173              
  Partials       41       41              

Files	Coverage Δ
common/flagdproxy/flagdproxy.go	89.52% <100.00%> (+0.82%)	⬆️
controllers/core/flagd/resources/deployment.go	96.66% <66.66%> (+2.10%)	⬆️
controllers/core/flagd/config.go	0.00% <0.00%> (ø)

Flag	Coverage Δ
unit-tests	86.63% <83.33%> (+0.11%)	⬆️

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

[cpitstick-latai]

@toddbaert I believe I've resolved all the issues you pointed out. I've largely followed your blueprint for adding labels and annotations for image pull secrets, but this also means I may have missed other places they should go. Still, I think this is worth merging to get this formally in as a supported feature.

[toddbaert]

@toddbaert I believe I've resolved all the issues you pointed out. I've largely followed your blueprint for adding labels and annotations for image pull secrets, but this also means I may have missed other places they should go. Still, I think this is worth merging to get this formally in as a supported feature.

Amazing work. I'm reviewing and testing this now.

[toddbaert]

Hey @cpitstick-latai ! This all looks good to me, but I tried to install via helm and I get an error (whether or not I pass any values for annotations/labels).

Things I did:

• pulled your branch
• ran make helm-package
• installed with helm upgrade --install open-feature-operator '/home/todd/git/open-feature-operator/charts/open-feature-operator-v0.7.0.tgz'

Then I got:

Error: UPGRADE FAILED: parse error at (open-feature-operator/templates/apps_v1_deployment_open-feature-operator-controller-manager.yaml:42): unexpected <range> in parenthesized pipeline

It seems like something isn't working with the templating

[cpitstick-latai]

Ok I'll take a look and do some thorough testing on my end!

[cpitstick-latai]

@toddbaert Alright I've updated it and done much more thorough testing. A couple notes:

• Sometimes when a container is injected, the original deployment has to have hostNetwork: true enabled. This doesn't always seem to be true; however, there may be an issue with my cluster.
• Looks like labels, annotations, and imagePullSecrets do not matter for injected pods, as they key off the settings of the original Pod the container is being injected into. So it's only with FlagD standalone and FlagD proxy mode that this matters (and I didn't specifically test those, but I did verify that the labels are being parsed correctly in the main.go function)

[cpitstick-latai]

The ugliest/most awkward parts are this line and its companion for annotations: {{ $labelKeys := keys .Values.labels -}}{{- $labelPairs := list -}}{{- range $key := $labelKeys -}}{{- $labelPairs = append $labelPairs (printf "%s:%s" $key (index $.Values.labels $key)) -}}{{- end -}}{{- join "," $labelPairs }}

I don't know how to write it better, but it does work and build properly.

[cpitstick-latai]

Maybe that nil check should be moved out so that it's always at least an empty map?

[toddbaert]

@cpitstick-latai I tested this thoroughly, including flagd-standalone and proxy modes. I did find one very small problem with the annotations if there's no annotations on a flagd deployment (there's a nil exception). I've fixed it with this commit; please make sure it makes sense to you and I will merge in the next 24hrs.

[cpitstick-latai]

It makes sense. I did merge the if statements a little so that it would make sure the map wasn't nil before the merge check. In this way, it's always an empty map rather than a nil map that's applied to the cluster, and then we don't need nesting!

We have a cyclomatic complexity issue now; however, it seems the additional conditionals tipped this function over the edge.

[toddbaert]

It makes sense. I did merge the if statements a little so that it would make sure the map wasn't nil before the merge check. In this way, it's always an empty map rather than a nil map that's applied to the cluster, and then we don't need nesting!

We have a cyclomatic complexity issue now; however, it seems the additional conditionals tipped this function over the edge.

It makes sense. I did merge the if statements a little so that it would make sure the map wasn't nil before the merge check. In this way, it's always an empty map rather than a nil map that's applied to the cluster, and then we don't need nesting!

We have a cyclomatic complexity issue now; however, it seems the additional conditionals tipped this function over the edge.

I've simplified my solution (it was really just nil annotations on the template): I now simply default the annotations on the template with the empty annotation map you created. That fixes the problem without more complexity: facebb5

[cpitstick-latai]

Looks good to me, feel free to merge this at your convenience and when you get some teammates to review it!