dra-evolution: device health in ResourcePool.Status

[pohly]

Excluded from #14 to limit the scope. See capacity_types.go.

To discuss:

• Who writes that status?
  After DRA: make kubelet independent of the resource.k8s.io API version kubernetes/kubernetes#125163 (implements
  KEP-4318: DRA: avoid kubelet API version dependency kubernetes/enhancements#4667), kubelet is not
  involved with publishing ResourcePools, they come directly from the driver.
• What information should be in it?
• Does it need to be a sub-resource? This would make it harder
  for a driver to publish a new device (spec) and its corresponding
  health information (status).

[pohly]

Potential use cases:

• The driver marks a device as "unhealthy", which implies that it should not be selected when allocating claims.
• An admininistrator marks a device as "in maintenance", with the same effect.
• A driver needs to inform some other component that a certain condition has been observed.

The last point can be solved by adding a https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Condition to the status. It would be up to the driver vendor to define their condition types, similar to how they describe their attributes.

Such an opaque condition would not tell the scheduler anything. We would need to define a "DontAllocate" condition type. But this type is the key in the conditions map, so both driver or admin would set it. Unsetting it becomes harder because there is no clear owner.

A node taint is closer. We could have different taints that all have the "don't allocate" effect, with different owners depending on the key. But is that a concept that we should copy? We cannot directly copy it, the TaintEffect definitions don't make sense for a device.

I am undecided which of these options would pass an API review.

@thockin?

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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.