feat: exposed customAntiAffinity

[kartikaysaxena]

[!warning] This is a public repository, ensure not to disclose:

• [ ] personal data beyond what is necessary for interacting with this pull request, nor
• [ ] business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• [ x] kind/feature
• [ ] kind/improvement
• [ ] kind/deprecation
• [ ] kind/documentation
• [ ] kind/clean-up
• [ ] kind/bug
• [ ] kind/other

Optional: Mark one or more of the following that are applicable:

[!important] Breaking changes should be marked kind/admin-change or kind/dev-change depending on type Critical security fixes should be marked with kind/security

• [ ] kind/admin-change
• [ ] kind/dev-change
• [ ] kind/security
• [ ] kind/adr

What does this PR do / why do we need this PR?

Fixes #2365, introduced a customLabel to avoid hardcoding given here for exposing customAntiAffinity

...

• Fixes #

Information to reviewers

Checklist

• [ ] Proper commit message prefix on all commits
• Change checks:
  • [ ] The change is transparent
  • [ ] The change is disruptive
  • [ ] The change requires no migration steps
  • [ ] The change requires migration steps
  • [ ] The change upgrades CRDs
  • [ ] The change updates the config and the schema
• Documentation checks:
  • [ ] The public documentation required no updates
  • [ ] The public documentation required an update - [link to change](set-me)
• Metrics checks:
  • [ ] The metrics are still exposed and present in Grafana after the change
  • [ ] The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
  • [ ] The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)
• Logs checks:
  • [ ] The logs do not show any errors after the change
• Pod Security Policy checks:
  • [ ] Any changed pod is covered by Pod Security Admission
  • [ ] Any changed pod is covered by Gatekeeper Pod Security Policies
  • [ ] The change does not cause any pods to be blocked by Pod Security Admission or Policies
• Network Policy checks:
  • [ ] Any changed pod is covered by Network Policies
  • [ ] The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • [ ] The change does not cause any unnecessary Kubernetes audit events
  • [ ] The change requires changes to Kubernetes audit policy
• Falco checks:
  • [ ] The change does not cause any alerts to be generated by Falco
• Bug checks:
  • [ ] The bug fix is covered by regression tests

[kartikaysaxena]

Hey @robinAwallace can you PTAL if I am going in the right direction?

[robinAwallace]

Hi @kartikaysaxena, thanks for contributing to compliantkubernetes.

The issue that you are working on wants the customAntiAffinity value for opensearch to be exposed in our config values and not really a custom label. Also, we have a policy not to update charts that are located under helmfile.d/upstream. As these are upstream charts, and should as such be updated upstream and not here.

So if you want to, you could update your PR to address the issue and not add labels. Thanks. :slightly_smiling_face:

[aarnq]

Hi @kartikaysaxena, I am sorry that we haven't gotten to your PR sooner. Thanks for addressing this issue!

I would like to propose a different solution to the problem, as we already have a full definition of the pod anti affinity in the config we could reuse that, so it actually makes sense. :smile:

It requires that you in here https://github.com/elastisys/compliantkubernetes-apps/blob/main/helmfile.d/values/opensearch/master.yaml.gotmpl#L23-L29 set the antiAffinity of the OpenSearch chart to "custom", then feed .Values.opensearch.masterNode.affinity.podAntiAffinity directly to the charts customAntiAffinity. Then we should have it without needing to change the config or schema.

Note that the files under helmfile.d/values/ acts as intermediate templating from the config/ values to the values that inputted to the helm charts.