Here's what it looked like before:
err="allocation of one or more pod claims failed. Claim test-dra5z9nh-resource-1an8wcr: failed allocating claim 4739f9a2-eedc-4702-ab17-e201e2dc0ad2. Claim test-dra5z9nh-resource-1bbdsj2: failed allocating claim e5525e5a-3397-40b4-a633-9ac354605303."
Some observations:
- Inserting the claim UID is just noise because it doesn't get logged anywhere else.
- Concatenating on a single line makes it hard to see the individual errors.
Joining with errors.Join leads to more readable output. The claim name only
gets inserted if not present already, to keep the individual error entries
short:
err=<
claim test-dralmx55-resource-1asvr5d: resources exhausted on node "scheduler-perf-dra-w62wm"
claim test-dralmx55-resource-1bqq6c9: resources exhausted on node "scheduler-perf-dra-w62wm"
>
Instead of emitting two log entries for new or updated ResourceClaim and
PodSchedulingContext, add the additional information for V(6) to the logger via
WithValues and emit one log entry. This makes the log shorter and easier to
read because related information is on one line.
github.com/docker/distribution/reference has a new home github.com/distribution/reference
and a new tag v0.5.0. Let's switch to that.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This change enables the external cloud provider by default for GCE
infrastructure. It is the result of several squashed commits, these are
their commit messages:
* no longer need to enable endpoinslices controller since GA
* use external by default
* DisableKubeletCloudCredentialProviders
* temp test feature gates
* Fix a job quota related deadlock
In case ResourceQuota is used and sets a max # of jobs, a CronJob may get
trapped in a deadlock:
1. Job quota for a namespace is reached.
2. CronJob controller can't create a new job, because quota is
reached.
3. Cleanup of jobs owned by a cronjob doesn't happen, because a
control loop iteration is finished because of an error to create a
job.
To fix this we stop early quitting from a control loop iteration when
cronjob reconciliation failed and always let old jobs to be cleaned up.
* Dont reorder imports
* Don't stop requeuing on reconciliation error
Previous code only logged the reconciliation error inside jm.sync() and
didn't return the reconciliation error to it's invoker
processNextWorkItem().
Adding a copy-paste back to avoid this issue.
* Remove copy-pasted cleanupFinishedJobs()
Now we always call jm.cleanupFinishedJobs() first and then
jm.syncCronJob().
We also extract cronJobCopy and updateStatus outside jm.syncCronJob
function and pass pointers to them in both jm.syncCronJob and
jm.cleanupFinishedJobs to make delayed updates handling more explicit
and not dependent on the order in which cleanupFinishedJobs and
syncCronJob are invoked.
* Return updateStatus bool instead of changing the reference
* Explicitly ignore err in tests to fix linter
I moved a simpler condition to the beginning of the function (when the error == nil). This has substantially streamlined the function for readability and comprehension of its logic flow.
From API call WithRange and WithPrefix work the same, they just set the range end.
The difference is when the range end is provided:
* WithRange(end) requires providing the end while calling
* WithPrefix() calculates the end based on key provided to the Get.
For example, those are equal:
* client.Get(ctx, "/pods/", WithPrefix())
* client.Get(ctx, "/pods/", WithRange(GetPrfixRangeEnd("/pods/")))
As keyPrefix is equal preparedKey there should not be a difference.
With the new busybox, ash has a built-in sleep command. Prior to this
change we were creating half the pids expected since `sleep` wasn't
actually launching a new binary. Use the full path to /bin/sleep which
avoids the built-in and actually launches a new process.
There were four issues in OpenAPI aggregation cleanup:
1. When removing an APIService, openAPIAggregationController was called
twice while openAPIV3AggregationController was never called, leading
to OpenAPI v3 for the APIService not cleaned up.
2. When removing a local APIService, v2 specAggregator should not return
ErrAPIServiceNotFound when it doesn't find the APIService because
local APIServices were never added to its cache, otherwise confusing
error logs would be generated. Besides, the method's comment
indicates that the desired behavior is that no error is returned if
the APIService does not exist.
3. When removing an APIService, v3 specProxier should update
openapiv2converter's cache, like when updating an APIService,
otherwise the API would not be removed from "/openapi/v3".
4. When v3 AggregationController reconciles an APIService, it should
stop requeueing it if it fails with ErrAPIServiceNotFound as the
APIService has been removed, like what v2 AggregationController does,
otherwise it would keep reconciling the APIService forever.
Signed-off-by: Quan Tian <qtian@vmware.com>
When defining a ClusterIP Service, we can specify externalIP, and the
traffic policy of externalIP is subject to externalTrafficPolicy.
However, the policy can't be set when type is not NodePort or
LoadBalancer, and will default to Cluster when kube-proxy processes the
Service.
This commit updates the defaulting and validation of Service to allow
specifying ExternalTrafficPolicy for ClusterIP Services with
ExternalIPs.
Signed-off-by: Quan Tian <qtian@vmware.com>
returnRV was was equal to withRev, but updated at different time.
When preparing the request they are set equal to each other.
The only difference was during the for loop.
returnRV was always set no matter if pagination was enabled, while withRev only when paginating.
