Telcodocs 2269: NUMAResourcesOperator: Support for schedulable control-plane nodes

[kquinn1204]

Version(s): 4.20 and main

Issue: https://issues.redhat.com/browse/TELCODOCS-2269

Link to docs preview: https://98666--ocpdocs-pr.netlify.app/openshift-enterprise/latest/scalability_and_performance/cnf-numa-aware-scheduling.html#cnf-numa-resource-operator-support-scheduling-cp_numa-aware

QE review:

• QE has approved this change.

Additional information:

[ocpdocs-previewbot]

🤖 Mon Oct 13 08:45:20 - Prow CI generated the docs preview:

https://98666--ocpdocs-pr.netlify.app/openshift-enterprise/latest/scalability_and_performance/cnf-numa-aware-scheduling.html

[amolnar-gh]

Nice work, lost of good info here! I only have one important question that I mentioned in one of the comments. Has the NUMA Resources Operator name been approved by branding and legal? I couldn't find it in the official product name list. Also, why is the abbreviation NROP and not just NRO?

Everything else is small but recurring:

• If you introduce an abbreviation (e.g. NROP), use it in the same module. I found that you introduce them but then don't use them in the rest of the module or not consistently. If you don't prefer using it, just don't introduce the abbreviation.
• Use backticks for YAML elements consistently.
• Define what things are (nodeGroups field or object or whatever)
• It's more like a preference for me but the "made schedulable" phrase doesn't sound right to me. I also wonder if it could cause issues during translation? Would it be possible to use "change to or updated to schedulable". "made" could be vague

[slovern]

Great stuff here. I just found a few things that might be worth a look.

[shajmakh]

Thanks @kquinn1204 for the work here, appreciated!
I left few comments. Overall I think it would be sufficient to point out that master nodes can now be part of the nodeGroups managed by the NRO CR under the condition they fulfill all the rules in order for the topology-aware scheduling to operate properly. Another point is regarding the verification section, when configuring "master" among the nodeGroups, we can avoid duplication and simply direct the user to the usual verification steps.
Most importantly, masters being supported in NROP is requires no special preparation apart from the usual one done for the worker pools and the operation of making the master nodes schedulable.

[shajmakh]

this is an example of a bad configuration. essentioally whatever applied to worker nodegroup should also apply to any node group, masters are no special from NROP perspective.

[shajmakh]

another example for a misconfiguration of the nodeGroup MCP, memory resource is missing

[kquinn1204]

@shajmakh I have revised the PR hopefully ready to be merged now. I have tried to install NUMA but facing some diffs with move to konflux

[kquinn1204]

Thanks @shajmakh I believe I have captured your feedback, really appreciate your feedback on this and once again learned a lot.

[rshemtov13]

Thanks @shajmakh for the review here I have nothing more to add to it.
From QE
/lgtm

[shajmakh]

Thanks @kquinn1204 for all the updates!
it LGTM with a small comment.

[openshift-ci]

New changes are detected. LGTM label has been removed.

[slovern]

Looking good. A few comments

[openshift-ci]

@kquinn1204: 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.

[slovern]

/cherrypick enterprise-4.20

[openshift-cherrypick-robot]

@slovern: new pull request created: #100429

In response to this:

/cherrypick enterprise-4.20

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.