Detect and label CPU Model Name

[lmdaly]

An addition to the CPU source that adds a string label with the CPU Model name (model name as described under /proc/cpuinfo for eg.)

For example: : "Intel(R) Xeon(R) CPU E5-XXXX"

The reason for this, in heterogeneous clusters, a workload that requires a specific platform feature or configuration needs to run on a particular model type, ensuring that the workload does not end up on an undesirable platform.

A latency sensitive workload may want to run on the latest architecture to reap the benefits of this new architecture, whereas infrastructure tasks can run on older generations as performance is not as important.

[marquiz]

Would it be better to split the information into smaller pieces, like:

cpu-cpuinfo.model="79"
cpu-cpuinfo.stepping="1"
cpu-cpuinfo.mhz="2200"

I think this would be a more reliable way of ensuring a certain generation of cpu. WDYT?

[lmdaly]

Yes, I think this would work,
Or if we could potentially get both in that would be good!

[ArangoGutierrez]

++

[ArangoGutierrez]

Just to raise awareness of this issue, I want to share a nice library that is targeting this issue

https://github.com/archspec/archspec

A library to track system architecture aspects incl. processor family & co

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[marquiz]

Maybe we should just start with model, stepping, and nominal clock frequency

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[marquiz]

/remove-lifecycle stale

[ArangoGutierrez]

I have created a side care container for NFD https://github.com/archspec/archspec-feature-discovery , leverage ArcSpec library, that give us the name of the microarch

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[marquiz]

/remove-lifecycle rotten

[MadhavJivrajani]

Is this issue available to be worked on?

[marquiz]

I think with #464 hopefully merged at some point this can be more useful

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[marquiz]

/remove-lifecycle stale

[ArangoGutierrez]

I have an example side-car container that helps with this https://github.com/archspec/archspec-feature-discovery

Deploy the Node-feature-Discovery with the extra option --extra-label-ns=archspec.io, then:

$ kubectl apply -f manifests/
namespace/archspec-feature-discovery created
serviceaccount/archspec-feature-discovery created
role.rbac.authorization.k8s.io/archspec-feature-discovery created
rolebinding.rbac.authorization.k8s.io/archspec-feature-discovery created
daemonset.apps/archspec-feature-discovery created

$ kubectl get all -n archspec-feature-discovery
NAME                                   READY   STATUS    RESTARTS   AGE
pod/archspec-feature-discovery-ddhnq   1/1     Running   0          7m21s
pod/archspec-feature-discovery-rr9ts   1/1     Running   0          7m21s

NAME                                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
daemonset.apps/archspec-feature-discovery   2         2         2       2            2           node-role.kubernetes.io/worker=   7m22

$kubectl get no -o json | jq .items[].metadata.labels |grep archspec
  "archspec.io/cpu.family": "6",
  "archspec.io/cpu.model": "79",
  "archspec.io/cpu.target": "haswell",
  "archspec.io/cpu.vendor": "GenuineIntel",
  "archspec.io/cpu.family": "6",
  "archspec.io/cpu.model": "79",
  "archspec.io/cpu.target": "haswell",
  "archspec.io/cpu.vendor": "GenuineIntel",

[ArangoGutierrez]

/help
/good-first-issue

[k8s-ci-robot]

@ArangoGutierrez:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/help
/good-first-issue

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/test-infra repository.

[AshwiniGhanwat]

I am working on this issue. Please assign this issue to me.

[zvonkok]

@fabiand Any requirements for kubeVirt I remember that some folks asked about CPU Model for kubeVirt as well?

[zvonkok]

@marquiz @ArangoGutierrez Should we think of a plugin system to enable such third party libs or do you think the side-car container is the way to go to extend NFDs detecting functionality?

[zvonkok]

One thing I dislike is that we are still using a hostMount which can cause some pain.

[zvonkok]

The other thing we thought about was a grpc plugin system a dedicated channel for extensions.

[marquiz]

@marquiz @ArangoGutierrez Should we think of a plugin system to enable such third party libs or do you think the side-car container is the way to go to extend NFDs detecting functionality?

I would go with side-car for now. And it doesn't need to be a side-car, it can be a separate pod.

One thing I dislike is that we are still using a hostMount which can cause some pain.

Could you elaborate a bit? What is the pain you're experiencing?

The other thing we thought about was a grpc plugin system a dedicated channel for extensions.

I wouldn't go there until there is a clear use case and reasoning to do this. It complicates matters - from the plugin's perspective, too, IMO. The extensions/communication is supposed to be node-local in any case.

For this particular issue (CPU detection) we shouldn't need any extra plugins. Just read/parse /proc/cpuinfo should do the job

[digambar15]

Can someone assign this issue to @AshwiniGhanwat as she is already working on it.

[ArangoGutierrez]

/assign AshwiniGhanwat

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[vaibhav2107]

/remove-lifecycle stale

[zvonkok]

@digambar15 @AshwiniGhanwat Any updates on this?

[ArangoGutierrez]

#792

[ArangoGutierrez]

/assign

[ArangoGutierrez]

/unassign AshwiniGhanwat

[ArangoGutierrez]

Hey @lmdaly thanks for this issue, can you verify if changes #792 fit your need, and if so, closing this issue :)

[marquiz]

I think lmdaly is not working in this area anymore.
/close

[k8s-ci-robot]

@marquiz: Closing this issue.

In response to this:

I think lmdaly is not working in this area anymore.
/close

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/test-infra repository.