When handling a PodSchedulingContext object, the code first checked for
unsuitable nodes and then tried to allocate if (and only if) the selected node
hadn't been found to be unsuitable.
If for whatever reason the selected node wasn't listed as potential node, then
scheduling got stuck because the allocation would fail and cause a return with
an error instead of updating the list of unsuitable nodes. This would be
retried with the same result.
To avoid this scenario, the selected node now also gets checked. This is better
than assuming a certain kube-scheduler behavior.
This problem occurred when experimenting with cluster autoscaling:
spec:
potentialNodes:
- gke-cluster-pohly-pool-dra-69b88e1e-bz6c
- gke-cluster-pohly-pool-dra-69b88e1e-fpvh
selectedNode: gke-cluster-pohly-default-pool-c9f60a43-6kxh
Why the scheduler wrote a spec like this is unclear. This was with Kubernetes
1.27 and the code has been updated since then, so perhaps it's resolved.
Kubernetes 1.28 introduced generated resource claim names, with the actual name
recorded in the pod status. As part of that change, the helper library for DRA
drivers was updated to match that behavior. Since then, driver deployments were
either compatible with Kubernetes 1.27 when using
k8s.io/dynamic-resource-allocation 0.27 or Kubernetes 1.28 when using 0.28,
but never both.
This was okay because this is an alpha feature, but it makes testing of DRA
drivers harder (in particular because cloud providers have not all updated to
1.28 yet) and can be fixed fairly easily. Therefore adding support for 1.27 is
worthwhile and reasonable.
The function generates bytes in the x={0-252} range and then
applies an y=(x mod 36) to obtain allowed token characters
from validBootstrapTokenChars[y].
Instead of using crypto/rand.Reader, use crypto/rand.Int()
that operates in the val={0-len(validBootstrapTokenChars))}.
Once a random index is generated, use simple operations
to obtain a random character in the a-z,0-9 character range.
This makes the character generation in constant-time.
dir field has been deprecated in favour of dirs field, so that
multiple directories can be specified in the rules in future
when publishing-bot moves from filter-branch to filter-repo
Signed-off-by: Akhil Mohan <makhil@vmware.com>
The SetStatusCondition and RemoveStatusCondition currently do not
indicate if they changed anything. In most cases that information is
necessary to determine if an Update of the object is needed. This change
adds a boolean return to them that indicate if they changed anything.
As the two functions had no return at all prior to this, this shouldn't
break anything.
Bumping govmomi to include an error check fix needed
to work with go1.20. We made this fix in the CI, but
were reliant on the text matching of error strings,
which is why it didn't catch the actual issue. This
Fix in b4eac19369
PR to bump govmomi in cloud-provider-vsphere: https://github.com/kubernetes/cloud-provider-vsphere/pull/738
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
The contains-group-resources was an implementation error, we specified
contains-group-kinds in the KEP.
Because it is in alpha, we simply switch to the new annotation.
We will recognize the old annotation and migrate existing alpha
applysets, but support for this migration can be removed in beta/GA of
applyset.
