At first glance, it seems that the fields storage.ListOptions.ProgressNotify and storage.ListOptions.Predicate.AllowWatchBookmarks
are the same. Unfortunately, this is not the case.
This PR documents the differences and motivations for why these fields are actually distinct.
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.
