NO-JIRA: Drop TuneD profiles with the same name and different content

[jmencak]

It is possible to create Tuned CRs with TuneD profiles of the same name.
This is problematic when the duplicate TuneD profiles have different
content. This causes periodic extraction of TuneD profiles and can lead
to TuneD restarts.

This change drops all instances of duplicate TuneD profiles and is a partial
fix for OCPBUGS-44559.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jmencak

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jmencak]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[MarSik]

Is storing this really necessary? The AllProfiles list already has this information and it is enough to just report the duplicate names in the status I'd say?

[jmencak]

You'd have to go through the AllProfiles list again when calculating the status and check their content. Same content is not a problem and I don't think we should make co/node-tuning degraded. The "cache" is an optimization. Data vs. CPU cycles. I'm for saving CPU cycles.

[jmencak]

An example of creating duplicate profiles with conflicting content:
Profile 1

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-profile-dup
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift profile
      include=openshift-node
      [sysctl]
      kernel.shmmni=8192
    name: openshift-profile
  recommend:
  - match:
    - label: profile
    priority: 20
    profile: openshift-profile

Profile 2

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-profile-dup2
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift profile
      include=openshift-node
      [sysctl]
      kernel.shmmni=8191
    name: openshift-profile
  recommend:
  - match:
    - label: profile
    priority: 20
    profile: openshift-profile

[MarSik]

I know this is cheaper than doing the count over AllProfiles here, but using the direct value instead of a precomputed cache might be easier to maintain.

[jmencak]

Yes, as I said above, it is cheaper.

[openshift-ci-robot]

@jmencak: This pull request explicitly references no jira issue.

In response to this:

It is possible to create Tuned CRs with TuneD profiles of the same name. This is problematic when the duplicate TuneD profiles have different content. While the problem is obvious when inspecting the operator logs, this configuration issue is serious enough it should be more visible.

This change makes the node-tuning ClusterOperator object Degraded when conflicting TuneD profiles are created. This in turn creates an alert for cluster administrators to deal with this misconfiguration.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[jmencak]

/hold
Unfortunately, as is, this will not fix the issue, not even partly. The Tuned CRs can be retrieved in random order.

[jmencak]

/unhold

[openshift-ci]

@jmencak: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.