yolokube/traefik-certmanager
yolokube/traefik-certmanager
Archived
3
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

fix(kubernetes): temporary solution for updated k8s python client
All checks were successful
ci/woodpecker/push/build Pipeline was successful
Details
ci/woodpecker/push/deploy Pipeline was successful
Details

Browse source
This commit is contained in:
Tom Neuber 2025-01-05 00:21:36 +01:00
parent 07d6fe7442
commit 977b5bca85
Signed by: tom
GPG key ID: F17EFE4272D89FF6
1477 changed files with 422337 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

13
kubernetes/docs/V1beta1ResourceClaimStatus.md Normal file
View file

@ -0,0 +1,13 @@
# V1beta1ResourceClaimStatus
ResourceClaimStatus tracks whether the resource has been allocated and what the result of that was.
## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**allocation** | [**V1beta1AllocationResult**](V1beta1AllocationResult.md) | | [optional]
**devices** | [**list[V1beta1AllocatedDeviceStatus]**](V1beta1AllocatedDeviceStatus.md) | Devices contains the status of each device allocated for this claim, as reported by the driver. This can include driver-specific information. Entries are owned by their respective drivers. | [optional]
**reserved_for** | [**list[V1beta1ResourceClaimConsumerReference]**](V1beta1ResourceClaimConsumerReference.md) | ReservedFor indicates which entities are currently allowed to use the claim. A Pod which references a ResourceClaim which is not reserved for that Pod will not be started. A claim that is in use or might be in use because it has been reserved must not get deallocated. In a cluster with multiple scheduler instances, two pods might get scheduled concurrently by different schedulers. When they reference the same ResourceClaim which already has reached its maximum number of consumers, only one pod can be scheduled. Both schedulers try to add their pod to the claim.status.reservedFor field, but only the update that reaches the API server first gets stored. The other one fails with an error and the scheduler which issued it knows that it must put the pod back into the queue, waiting for the ResourceClaim to become usable again. There can be at most 32 such reservations. This may get increased in the future, but not reduced. | [optional]
[[Back to Model list]](../README.md#documentation-for-models) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to README]](../README.md)