kubernetes.resource.k8s.io/v1alpha3.ResourceClaimPatch

Conditions contains the latest observation of the device's state. If the device has been configured according to the class and claim config references, the Ready condition should be True.

Must not contain more than 8 entries.

Data contains arbitrary driver-specific data.

The length of the raw data must be smaller or equal to 10 Ki.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Conditions contains the latest observation of the device's state. If the device has been configured according to the class and claim config references, the Ready condition should be True.

Must not contain more than 8 entries.

Data contains arbitrary driver-specific data.

The length of the raw data must be smaller or equal to 10 Ki.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Conditions contains the latest observation of the device's state. If the device has been configured according to the class and claim config references, the Ready condition should be True.

Must not contain more than 8 entries.

Data contains arbitrary driver-specific data.

The length of the raw data must be smaller or equal to 10 Ki.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Conditions contains the latest observation of the device's state. If the device has been configured according to the class and claim config references, the Ready condition should be True.

Must not contain more than 8 entries.

Data contains arbitrary driver-specific data.

The length of the raw data must be smaller or equal to 10 Ki.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Conditions contains the latest observation of the device's state. If the device has been configured according to the class and claim config references, the Ready condition should be True.

Must not contain more than 8 entries.

Data contains arbitrary driver-specific data.

The length of the raw data must be smaller or equal to 10 Ki.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Conditions contains the latest observation of the device's state. If the device has been configured according to the class and claim config references, the Ready condition should be True.

Must not contain more than 8 entries.

Data contains arbitrary driver-specific data.

The length of the raw data must be smaller or equal to 10 Ki.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Controller is the name of the DRA driver which handled the allocation. That driver is also responsible for deallocating the claim. It is empty when the claim can be deallocated without involving a driver.

A driver may allocate devices provided by other drivers, so this driver name here can be different from the driver names listed for the results.

This is an alpha field and requires enabling the DRAControlPlaneController feature gate.

Controller is the name of the DRA driver which handled the allocation. That driver is also responsible for deallocating the claim. It is empty when the claim can be deallocated without involving a driver.

A driver may allocate devices provided by other drivers, so this driver name here can be different from the driver names listed for the results.

This is an alpha field and requires enabling the DRAControlPlaneController feature gate.

Controller is the name of the DRA driver which handled the allocation. That driver is also responsible for deallocating the claim. It is empty when the claim can be deallocated without involving a driver.

A driver may allocate devices provided by other drivers, so this driver name here can be different from the driver names listed for the results.

This is an alpha field and requires enabling the DRAControlPlaneController feature gate.

Controller is the name of the DRA driver which handled the allocation. That driver is also responsible for deallocating the claim. It is empty when the claim can be deallocated without involving a driver.

A driver may allocate devices provided by other drivers, so this driver name here can be different from the driver names listed for the results.

This is an alpha field and requires enabling the DRAControlPlaneController feature gate.

Controller is the name of the DRA driver which handled the allocation. That driver is also responsible for deallocating the claim. It is empty when the claim can be deallocated without involving a driver.

A driver may allocate devices provided by other drivers, so this driver name here can be different from the driver names listed for the results.

This is an alpha field and requires enabling the DRAControlPlaneController feature gate.

Controller is the name of the DRA driver which handled the allocation. That driver is also responsible for deallocating the claim. It is empty when the claim can be deallocated without involving a driver.

A driver may allocate devices provided by other drivers, so this driver name here can be different from the driver names listed for the results.

This is an alpha field and requires enabling the DRAControlPlaneController feature gate.

Expression is a CEL expression which evaluates a single device. It must evaluate to true when the device under consideration satisfies the desired criteria, and false when it does not. Any other result is an error and causes allocation of devices to abort.

The expression's input is an object named "device", which carries the following properties:

• driver (string): the name of the driver which defines this device.
• attributes (map[string]object): the device's attributes, grouped by prefix (e.g. device.attributes["dra.example.com"] evaluates to an object with all of the attributes which were prefixed by "dra.example.com".
• capacity (map[string]object): the device's capacities, grouped by prefix.

Example: Consider a device with driver="dra.example.com", which exposes two attributes named "model" and "ext.example.com/family" and which exposes one capacity named "modules". This input to this expression would have the following fields:

device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

The device.driver field can be used to check for a specific driver, either as a high-level precondition (i.e. you only want to consider devices from this driver) or as part of a multi-clause expression that is meant to consider devices from different drivers.

The value type of each attribute is defined by the device definition, and users who write these expressions must consult the documentation for their specific drivers. The value type of each capacity is Quantity.

If an unknown prefix is used as a lookup in either device.attributes or device.capacity, an empty map will be returned. Any reference to an unknown field will cause an evaluation error and allocation to abort.

A robust expression should check for the existence of attributes before referencing them.

For ease of use, the cel.bind() function is enabled, and can be used to simplify expressions that access multiple attributes with the same domain. For example:

cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

The length of the expression must be smaller or equal to 10 Ki. The cost of evaluating it is also limited based on the estimated number of logical steps.

Expression is a CEL expression which evaluates a single device. It must evaluate to true when the device under consideration satisfies the desired criteria, and false when it does not. Any other result is an error and causes allocation of devices to abort.

The expression's input is an object named "device", which carries the following properties:

• driver (string): the name of the driver which defines this device.
• attributes (map[string]object): the device's attributes, grouped by prefix (e.g. device.attributes["dra.example.com"] evaluates to an object with all of the attributes which were prefixed by "dra.example.com".
• capacity (map[string]object): the device's capacities, grouped by prefix.

Example: Consider a device with driver="dra.example.com", which exposes two attributes named "model" and "ext.example.com/family" and which exposes one capacity named "modules". This input to this expression would have the following fields:

device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

The device.driver field can be used to check for a specific driver, either as a high-level precondition (i.e. you only want to consider devices from this driver) or as part of a multi-clause expression that is meant to consider devices from different drivers.

The value type of each attribute is defined by the device definition, and users who write these expressions must consult the documentation for their specific drivers. The value type of each capacity is Quantity.

If an unknown prefix is used as a lookup in either device.attributes or device.capacity, an empty map will be returned. Any reference to an unknown field will cause an evaluation error and allocation to abort.

A robust expression should check for the existence of attributes before referencing them.

For ease of use, the cel.bind() function is enabled, and can be used to simplify expressions that access multiple attributes with the same domain. For example:

cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

The length of the expression must be smaller or equal to 10 Ki. The cost of evaluating it is also limited based on the estimated number of logical steps.

Expression is a CEL expression which evaluates a single device. It must evaluate to true when the device under consideration satisfies the desired criteria, and false when it does not. Any other result is an error and causes allocation of devices to abort.

The expression's input is an object named "device", which carries the following properties:

• driver (string): the name of the driver which defines this device.
• attributes (map[string]object): the device's attributes, grouped by prefix (e.g. device.attributes["dra.example.com"] evaluates to an object with all of the attributes which were prefixed by "dra.example.com".
• capacity (map[string]object): the device's capacities, grouped by prefix.

Example: Consider a device with driver="dra.example.com", which exposes two attributes named "model" and "ext.example.com/family" and which exposes one capacity named "modules". This input to this expression would have the following fields:

device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

The device.driver field can be used to check for a specific driver, either as a high-level precondition (i.e. you only want to consider devices from this driver) or as part of a multi-clause expression that is meant to consider devices from different drivers.

The value type of each attribute is defined by the device definition, and users who write these expressions must consult the documentation for their specific drivers. The value type of each capacity is Quantity.

If an unknown prefix is used as a lookup in either device.attributes or device.capacity, an empty map will be returned. Any reference to an unknown field will cause an evaluation error and allocation to abort.

A robust expression should check for the existence of attributes before referencing them.

For ease of use, the cel.bind() function is enabled, and can be used to simplify expressions that access multiple attributes with the same domain. For example:

cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

The length of the expression must be smaller or equal to 10 Ki. The cost of evaluating it is also limited based on the estimated number of logical steps.

Expression is a CEL expression which evaluates a single device. It must evaluate to true when the device under consideration satisfies the desired criteria, and false when it does not. Any other result is an error and causes allocation of devices to abort.

The expression's input is an object named "device", which carries the following properties:

• driver (string): the name of the driver which defines this device.
• attributes (map[string]object): the device's attributes, grouped by prefix (e.g. device.attributes["dra.example.com"] evaluates to an object with all of the attributes which were prefixed by "dra.example.com".
• capacity (map[string]object): the device's capacities, grouped by prefix.

Example: Consider a device with driver="dra.example.com", which exposes two attributes named "model" and "ext.example.com/family" and which exposes one capacity named "modules". This input to this expression would have the following fields:

device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

The device.driver field can be used to check for a specific driver, either as a high-level precondition (i.e. you only want to consider devices from this driver) or as part of a multi-clause expression that is meant to consider devices from different drivers.

The value type of each attribute is defined by the device definition, and users who write these expressions must consult the documentation for their specific drivers. The value type of each capacity is Quantity.

If an unknown prefix is used as a lookup in either device.attributes or device.capacity, an empty map will be returned. Any reference to an unknown field will cause an evaluation error and allocation to abort.

A robust expression should check for the existence of attributes before referencing them.

For ease of use, the cel.bind() function is enabled, and can be used to simplify expressions that access multiple attributes with the same domain. For example:

cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

The length of the expression must be smaller or equal to 10 Ki. The cost of evaluating it is also limited based on the estimated number of logical steps.

Expression is a CEL expression which evaluates a single device. It must evaluate to true when the device under consideration satisfies the desired criteria, and false when it does not. Any other result is an error and causes allocation of devices to abort.

The expression's input is an object named "device", which carries the following properties:

• driver (string): the name of the driver which defines this device.
• attributes (map[string]object): the device's attributes, grouped by prefix (e.g. device.attributes["dra.example.com"] evaluates to an object with all of the attributes which were prefixed by "dra.example.com".
• capacity (map[string]object): the device's capacities, grouped by prefix.

Example: Consider a device with driver="dra.example.com", which exposes two attributes named "model" and "ext.example.com/family" and which exposes one capacity named "modules". This input to this expression would have the following fields:

device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

The device.driver field can be used to check for a specific driver, either as a high-level precondition (i.e. you only want to consider devices from this driver) or as part of a multi-clause expression that is meant to consider devices from different drivers.

The value type of each attribute is defined by the device definition, and users who write these expressions must consult the documentation for their specific drivers. The value type of each capacity is Quantity.

If an unknown prefix is used as a lookup in either device.attributes or device.capacity, an empty map will be returned. Any reference to an unknown field will cause an evaluation error and allocation to abort.

A robust expression should check for the existence of attributes before referencing them.

For ease of use, the cel.bind() function is enabled, and can be used to simplify expressions that access multiple attributes with the same domain. For example:

cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

The length of the expression must be smaller or equal to 10 Ki. The cost of evaluating it is also limited based on the estimated number of logical steps.

Expression is a CEL expression which evaluates a single device. It must evaluate to true when the device under consideration satisfies the desired criteria, and false when it does not. Any other result is an error and causes allocation of devices to abort.

The expression's input is an object named "device", which carries the following properties:

• driver (string): the name of the driver which defines this device.
• attributes (map[string]object): the device's attributes, grouped by prefix (e.g. device.attributes["dra.example.com"] evaluates to an object with all of the attributes which were prefixed by "dra.example.com".
• capacity (map[string]object): the device's capacities, grouped by prefix.

Example: Consider a device with driver="dra.example.com", which exposes two attributes named "model" and "ext.example.com/family" and which exposes one capacity named "modules". This input to this expression would have the following fields:

device.driver
device.attributes["dra.example.com"].model
device.attributes["ext.example.com"].family
device.capacity["dra.example.com"].modules

The device.driver field can be used to check for a specific driver, either as a high-level precondition (i.e. you only want to consider devices from this driver) or as part of a multi-clause expression that is meant to consider devices from different drivers.

The value type of each attribute is defined by the device definition, and users who write these expressions must consult the documentation for their specific drivers. The value type of each capacity is Quantity.

If an unknown prefix is used as a lookup in either device.attributes or device.capacity, an empty map will be returned. Any reference to an unknown field will cause an evaluation error and allocation to abort.

A robust expression should check for the existence of attributes before referencing them.

For ease of use, the cel.bind() function is enabled, and can be used to simplify expressions that access multiple attributes with the same domain. For example:

cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)

The length of the expression must be smaller or equal to 10 Ki. The cost of evaluating it is also limited based on the estimated number of logical steps.

Requests lists the names of requests where the configuration applies. If empty, its applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, its applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, its applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, its applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, its applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, its applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

This field is a combination of all the claim and class configuration parameters. Drivers can distinguish between those based on a flag.

This includes configuration parameters for drivers which have no allocated devices in the result because it is up to the drivers which configuration parameters they support. They can silently ignore unknown configuration parameters.

This field is a combination of all the claim and class configuration parameters. Drivers can distinguish between those based on a flag.

This includes configuration parameters for drivers which have no allocated devices in the result because it is up to the drivers which configuration parameters they support. They can silently ignore unknown configuration parameters.

This field is a combination of all the claim and class configuration parameters. Drivers can distinguish between those based on a flag.

This includes configuration parameters for drivers which have no allocated devices in the result because it is up to the drivers which configuration parameters they support. They can silently ignore unknown configuration parameters.

This field is a combination of all the claim and class configuration parameters. Drivers can distinguish between those based on a flag.

This includes configuration parameters for drivers which have no allocated devices in the result because it is up to the drivers which configuration parameters they support. They can silently ignore unknown configuration parameters.

This field is a combination of all the claim and class configuration parameters. Drivers can distinguish between those based on a flag.

This includes configuration parameters for drivers which have no allocated devices in the result because it is up to the drivers which configuration parameters they support. They can silently ignore unknown configuration parameters.

This field is a combination of all the claim and class configuration parameters. Drivers can distinguish between those based on a flag.

This includes configuration parameters for drivers which have no allocated devices in the result because it is up to the drivers which configuration parameters they support. They can silently ignore unknown configuration parameters.

Requests lists the names of requests where the configuration applies. If empty, it applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, it applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, it applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, it applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, it applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

Requests lists the names of requests where the configuration applies. If empty, it applies to all requests.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the configuration applies to all subrequests.

MatchAttribute requires that all devices in question have this attribute and that its type and value are the same across those devices.

For example, if you specified "dra.example.com/numa" (a hypothetical example!), then only devices in the same NUMA node will be chosen. A device which does not have that attribute will not be chosen. All devices should use a value of the same type for this attribute because that is part of its specification, but if one device doesn't, then it also will not be chosen.

Must include the domain qualifier.

Requests is a list of the one or more requests in this claim which must co-satisfy this constraint. If a request is fulfilled by multiple devices, then all of the devices must satisfy the constraint. If this is not specified, this constraint applies to all requests in this claim.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the constraint applies to all subrequests.

MatchAttribute requires that all devices in question have this attribute and that its type and value are the same across those devices.

For example, if you specified "dra.example.com/numa" (a hypothetical example!), then only devices in the same NUMA node will be chosen. A device which does not have that attribute will not be chosen. All devices should use a value of the same type for this attribute because that is part of its specification, but if one device doesn't, then it also will not be chosen.

Must include the domain qualifier.

Requests is a list of the one or more requests in this claim which must co-satisfy this constraint. If a request is fulfilled by multiple devices, then all of the devices must satisfy the constraint. If this is not specified, this constraint applies to all requests in this claim.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the constraint applies to all subrequests.

MatchAttribute requires that all devices in question have this attribute and that its type and value are the same across those devices.

For example, if you specified "dra.example.com/numa" (a hypothetical example!), then only devices in the same NUMA node will be chosen. A device which does not have that attribute will not be chosen. All devices should use a value of the same type for this attribute because that is part of its specification, but if one device doesn't, then it also will not be chosen.

Must include the domain qualifier.

Requests is a list of the one or more requests in this claim which must co-satisfy this constraint. If a request is fulfilled by multiple devices, then all of the devices must satisfy the constraint. If this is not specified, this constraint applies to all requests in this claim.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the constraint applies to all subrequests.

MatchAttribute requires that all devices in question have this attribute and that its type and value are the same across those devices.

For example, if you specified "dra.example.com/numa" (a hypothetical example!), then only devices in the same NUMA node will be chosen. A device which does not have that attribute will not be chosen. All devices should use a value of the same type for this attribute because that is part of its specification, but if one device doesn't, then it also will not be chosen.

Must include the domain qualifier.

Requests is a list of the one or more requests in this claim which must co-satisfy this constraint. If a request is fulfilled by multiple devices, then all of the devices must satisfy the constraint. If this is not specified, this constraint applies to all requests in this claim.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the constraint applies to all subrequests.

MatchAttribute requires that all devices in question have this attribute and that its type and value are the same across those devices.

For example, if you specified "dra.example.com/numa" (a hypothetical example!), then only devices in the same NUMA node will be chosen. A device which does not have that attribute will not be chosen. All devices should use a value of the same type for this attribute because that is part of its specification, but if one device doesn't, then it also will not be chosen.

Must include the domain qualifier.

Requests is a list of the one or more requests in this claim which must co-satisfy this constraint. If a request is fulfilled by multiple devices, then all of the devices must satisfy the constraint. If this is not specified, this constraint applies to all requests in this claim.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the constraint applies to all subrequests.

MatchAttribute requires that all devices in question have this attribute and that its type and value are the same across those devices.

For example, if you specified "dra.example.com/numa" (a hypothetical example!), then only devices in the same NUMA node will be chosen. A device which does not have that attribute will not be chosen. All devices should use a value of the same type for this attribute because that is part of its specification, but if one device doesn't, then it also will not be chosen.

Must include the domain qualifier.

Requests is a list of the one or more requests in this claim which must co-satisfy this constraint. If a request is fulfilled by multiple devices, then all of the devices must satisfy the constraint. If this is not specified, this constraint applies to all requests in this claim.

References to subrequests must include the name of the main request and may include the subrequest using the format [/]. If just the main request is given, the constraint applies to all subrequests.

AdminAccess indicates that this device was allocated for administrative access. See the corresponding request field for a definition of mode.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Request is the name of the request in the claim which caused this device to be allocated. If it references a subrequest in the firstAvailable list on a DeviceRequest, this field must include both the name of the main request and the subrequest using the format /.

Multiple devices may have been allocated per request.

A copy of all tolerations specified in the request at the time when the device got allocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this device was allocated for administrative access. See the corresponding request field for a definition of mode.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Request is the name of the request in the claim which caused this device to be allocated. If it references a subrequest in the firstAvailable list on a DeviceRequest, this field must include both the name of the main request and the subrequest using the format /.

Multiple devices may have been allocated per request.

A copy of all tolerations specified in the request at the time when the device got allocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this device was allocated for administrative access. See the corresponding request field for a definition of mode.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Request is the name of the request in the claim which caused this device to be allocated. If it references a subrequest in the firstAvailable list on a DeviceRequest, this field must include both the name of the main request and the subrequest using the format /.

Multiple devices may have been allocated per request.

A copy of all tolerations specified in the request at the time when the device got allocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this device was allocated for administrative access. See the corresponding request field for a definition of mode.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Request is the name of the request in the claim which caused this device to be allocated. If it references a subrequest in the firstAvailable list on a DeviceRequest, this field must include both the name of the main request and the subrequest using the format /.

Multiple devices may have been allocated per request.

A copy of all tolerations specified in the request at the time when the device got allocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this device was allocated for administrative access. See the corresponding request field for a definition of mode.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Request is the name of the request in the claim which caused this device to be allocated. If it references a subrequest in the firstAvailable list on a DeviceRequest, this field must include both the name of the main request and the subrequest using the format /.

Multiple devices may have been allocated per request.

A copy of all tolerations specified in the request at the time when the device got allocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this device was allocated for administrative access. See the corresponding request field for a definition of mode.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

Driver specifies the name of the DRA driver whose kubelet plugin should be invoked to process the allocation once the claim is needed on a node.

Must be a DNS subdomain and should end with a DNS domain owned by the vendor of the driver.

This name together with the driver name and the device name field identify which device was allocated (<driver name>/<pool name>/<device name>).

Must not be longer than 253 characters and may contain one or more DNS sub-domains separated by slashes.

Request is the name of the request in the claim which caused this device to be allocated. If it references a subrequest in the firstAvailable list on a DeviceRequest, this field must include both the name of the main request and the subrequest using the format /.

Multiple devices may have been allocated per request.

A copy of all tolerations specified in the request at the time when the device got allocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this is a claim for administrative access to the device(s). Claims with AdminAccess are expected to be used for monitoring or other management services for a device. They ignore all ordinary claims to the device with respect to access modes and any resource allocations.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. At least one device must exist on the node for the allocation to succeed. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

Count is used only when the count mode is "ExactCount". Must be greater than zero. If AllocationMode is ExactCount and this field is not specified, the default is one.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this request.

A class is required if no subrequests are specified in the firstAvailable list and no class can be set if subrequests are specified in the firstAvailable list. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

FirstAvailable contains subrequests, of which exactly one will be satisfied by the scheduler to satisfy this request. It tries to satisfy them in the order in which they are listed here. So if there are two entries in the list, the scheduler will only check the second one if it determines that the first one cannot be used.

This field may only be set in the entries of DeviceClaim.Requests.

DRA does not yet implement scoring, so the scheduler will select the first set of devices that satisfies all the requests in the claim. And if the requirements can be satisfied on more than one node, other scheduling features will determine which node is chosen. This means that the set of devices allocated to a claim might not be the optimal set available to the cluster. Scoring will be implemented later.

Name can be used to reference this request in a pod.spec.containers[].resources.claims entry and in a constraint of the claim.

Must be a DNS label.

Selectors define criteria which must be satisfied by a specific device in order for that device to be considered for this request. All selectors must be satisfied for a device to be considered.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this is a claim for administrative access to the device(s). Claims with AdminAccess are expected to be used for monitoring or other management services for a device. They ignore all ordinary claims to the device with respect to access modes and any resource allocations.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. At least one device must exist on the node for the allocation to succeed. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

Count is used only when the count mode is "ExactCount". Must be greater than zero. If AllocationMode is ExactCount and this field is not specified, the default is one.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this request.

A class is required if no subrequests are specified in the firstAvailable list and no class can be set if subrequests are specified in the firstAvailable list. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

FirstAvailable contains subrequests, of which exactly one will be satisfied by the scheduler to satisfy this request. It tries to satisfy them in the order in which they are listed here. So if there are two entries in the list, the scheduler will only check the second one if it determines that the first one cannot be used.

This field may only be set in the entries of DeviceClaim.Requests.

DRA does not yet implement scoring, so the scheduler will select the first set of devices that satisfies all the requests in the claim. And if the requirements can be satisfied on more than one node, other scheduling features will determine which node is chosen. This means that the set of devices allocated to a claim might not be the optimal set available to the cluster. Scoring will be implemented later.

Name can be used to reference this request in a pod.spec.containers[].resources.claims entry and in a constraint of the claim.

Must be a DNS label.

Selectors define criteria which must be satisfied by a specific device in order for that device to be considered for this request. All selectors must be satisfied for a device to be considered.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this is a claim for administrative access to the device(s). Claims with AdminAccess are expected to be used for monitoring or other management services for a device. They ignore all ordinary claims to the device with respect to access modes and any resource allocations.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. At least one device must exist on the node for the allocation to succeed. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

Count is used only when the count mode is "ExactCount". Must be greater than zero. If AllocationMode is ExactCount and this field is not specified, the default is one.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this request.

A class is required if no subrequests are specified in the firstAvailable list and no class can be set if subrequests are specified in the firstAvailable list. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

FirstAvailable contains subrequests, of which exactly one will be satisfied by the scheduler to satisfy this request. It tries to satisfy them in the order in which they are listed here. So if there are two entries in the list, the scheduler will only check the second one if it determines that the first one cannot be used.

This field may only be set in the entries of DeviceClaim.Requests.

DRA does not yet implement scoring, so the scheduler will select the first set of devices that satisfies all the requests in the claim. And if the requirements can be satisfied on more than one node, other scheduling features will determine which node is chosen. This means that the set of devices allocated to a claim might not be the optimal set available to the cluster. Scoring will be implemented later.

Name can be used to reference this request in a pod.spec.containers[].resources.claims entry and in a constraint of the claim.

Must be a DNS label.

Selectors define criteria which must be satisfied by a specific device in order for that device to be considered for this request. All selectors must be satisfied for a device to be considered.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this is a claim for administrative access to the device(s). Claims with AdminAccess are expected to be used for monitoring or other management services for a device. They ignore all ordinary claims to the device with respect to access modes and any resource allocations.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. At least one device must exist on the node for the allocation to succeed. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

Count is used only when the count mode is "ExactCount". Must be greater than zero. If AllocationMode is ExactCount and this field is not specified, the default is one.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this request.

A class is required if no subrequests are specified in the firstAvailable list and no class can be set if subrequests are specified in the firstAvailable list. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

FirstAvailable contains subrequests, of which exactly one will be satisfied by the scheduler to satisfy this request. It tries to satisfy them in the order in which they are listed here. So if there are two entries in the list, the scheduler will only check the second one if it determines that the first one cannot be used.

This field may only be set in the entries of DeviceClaim.Requests.

DRA does not yet implement scoring, so the scheduler will select the first set of devices that satisfies all the requests in the claim. And if the requirements can be satisfied on more than one node, other scheduling features will determine which node is chosen. This means that the set of devices allocated to a claim might not be the optimal set available to the cluster. Scoring will be implemented later.

Name can be used to reference this request in a pod.spec.containers[].resources.claims entry and in a constraint of the claim.

Must be a DNS label.

Selectors define criteria which must be satisfied by a specific device in order for that device to be considered for this request. All selectors must be satisfied for a device to be considered.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this is a claim for administrative access to the device(s). Claims with AdminAccess are expected to be used for monitoring or other management services for a device. They ignore all ordinary claims to the device with respect to access modes and any resource allocations.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. At least one device must exist on the node for the allocation to succeed. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

Count is used only when the count mode is "ExactCount". Must be greater than zero. If AllocationMode is ExactCount and this field is not specified, the default is one.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this request.

A class is required if no subrequests are specified in the firstAvailable list and no class can be set if subrequests are specified in the firstAvailable list. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

FirstAvailable contains subrequests, of which exactly one will be satisfied by the scheduler to satisfy this request. It tries to satisfy them in the order in which they are listed here. So if there are two entries in the list, the scheduler will only check the second one if it determines that the first one cannot be used.

This field may only be set in the entries of DeviceClaim.Requests.

DRA does not yet implement scoring, so the scheduler will select the first set of devices that satisfies all the requests in the claim. And if the requirements can be satisfied on more than one node, other scheduling features will determine which node is chosen. This means that the set of devices allocated to a claim might not be the optimal set available to the cluster. Scoring will be implemented later.

Name can be used to reference this request in a pod.spec.containers[].resources.claims entry and in a constraint of the claim.

Must be a DNS label.

Selectors define criteria which must be satisfied by a specific device in order for that device to be considered for this request. All selectors must be satisfied for a device to be considered.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AdminAccess indicates that this is a claim for administrative access to the device(s). Claims with AdminAccess are expected to be used for monitoring or other management services for a device. They ignore all ordinary claims to the device with respect to access modes and any resource allocations.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRAAdminAccess feature gate. Admin access is disabled if this field is unset or set to false, otherwise it is enabled.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. At least one device must exist on the node for the allocation to succeed. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

Count is used only when the count mode is "ExactCount". Must be greater than zero. If AllocationMode is ExactCount and this field is not specified, the default is one.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this request.

A class is required if no subrequests are specified in the firstAvailable list and no class can be set if subrequests are specified in the firstAvailable list. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

FirstAvailable contains subrequests, of which exactly one will be satisfied by the scheduler to satisfy this request. It tries to satisfy them in the order in which they are listed here. So if there are two entries in the list, the scheduler will only check the second one if it determines that the first one cannot be used.

This field may only be set in the entries of DeviceClaim.Requests.

DRA does not yet implement scoring, so the scheduler will select the first set of devices that satisfies all the requests in the claim. And if the requirements can be satisfied on more than one node, other scheduling features will determine which node is chosen. This means that the set of devices allocated to a claim might not be the optimal set available to the cluster. Scoring will be implemented later.

Name can be used to reference this request in a pod.spec.containers[].resources.claims entry and in a constraint of the claim.

Must be a DNS label.

Selectors define criteria which must be satisfied by a specific device in order for that device to be considered for this request. All selectors must be satisfied for a device to be considered.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This field can only be set when deviceClassName is set and no subrequests are specified in the firstAvailable list.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this subrequest.

A class is required. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

Name can be used to reference this subrequest in the list of constraints or the list of configurations for the claim. References must use the format /.

Must be a DNS label.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this subrequest.

A class is required. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

Name can be used to reference this subrequest in the list of constraints or the list of configurations for the claim. References must use the format /.

Must be a DNS label.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this subrequest.

A class is required. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

Name can be used to reference this subrequest in the list of constraints or the list of configurations for the claim. References must use the format /.

Must be a DNS label.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this subrequest.

A class is required. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

Name can be used to reference this subrequest in the list of constraints or the list of configurations for the claim. References must use the format /.

Must be a DNS label.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this subrequest.

A class is required. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.

Name can be used to reference this subrequest in the list of constraints or the list of configurations for the claim. References must use the format /.

Must be a DNS label.

If specified, the request's tolerations.

Tolerations for NoSchedule are required to allocate a device which has a taint with that effect. The same applies to NoExecute.

In addition, should any of the allocated devices get tainted with NoExecute after allocation and that effect is not tolerated, then all pods consuming the ResourceClaim get deleted to evict them. The scheduler will not let new pods reserve the claim while it has these tainted devices. Once all pods are evicted, the claim will get deallocated.

The maximum number of tolerations is 16.

This is an alpha field and requires enabling the DRADeviceTaints feature gate.

AllocationMode and its related fields define how devices are allocated to satisfy this request. Supported values are:

• ExactCount: This request is for a specific number of devices. This is the default. The exact number is provided in the count field.

• All: This request is for all of the matching devices in a pool. Allocation will fail if some devices are already allocated, unless adminAccess is requested.

If AllocationMode is not specified, the default mode is ExactCount. If the mode is ExactCount and count is not specified, the default count is one. Any other requests must specify this field.

More modes may get added in the future. Clients must refuse to handle requests with unknown modes.

DeviceClassName references a specific DeviceClass, which can define additional configuration and selectors to be inherited by this subrequest.

A class is required. Which classes are available depends on the cluster.

Administrators may use this to restrict which devices may get requested by only installing classes with selectors for permitted devices. If users are free to request anything without restrictions, then administrators can create an empty DeviceClass for users to reference.