The fact that we're building the OpenAPI using the proto.Models is an
implementation detail that we shouldn't have to expose. Since we're
going to change the way this is transformed, let's first hide it behind
the common NewTypeConverter so that the next change is transparent.
This will also enable other clean-ups like hiding the gvkParser which
shouldn't be exposed and prevent some refactoring.
If we were to add new fields in TimeoutContext, the current users of
NewFrameworkWithCustomTimeouts might run into failures unless they get modified
to also set those new fields. This is error-prone.
A better approach is to let users of NewFrameworkWithCustomTimeouts override
fields by setting just those and use the normal defaults for the others.
This came up when updating go-oidc. After updating go-oidc (with its
dependency tree), cloud.google.com/go was no longer used as a package
import, but still listed in the module dependency graph; as a result,
"go mod vendor" no longer pulled in cloud.google.com/go itself, but
update-vendor-licenses.sh still wanted a license file for it since it
appeared in the list of modules.
This scenario is already supposed to be handled: when a module doesn't
contain any *files* as first-level content, if the number of
subdirectories it contains *equals* the number of submodules it
contains (excluding itself), the module is skipped. This fails for
cloud.google.com/go because several submodules are included in the
module dependency graph but aren't actually used, and therefore not
vendored.
Updating the test to check that the number of subdirectories is less
than or equal to the number of expected submodules fixes this.
The correct fix would be to process the submodules first, keeping a
note of which ones really have content, then check that the top-level
module only contains subdirectories corresponding to those modules;
but it's not clear to me that this is worth the effort (especially in
a shell script).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
This is an ugly-but-simple rewrite (particularly involving having to
rewrite "single Endpoints with multiple Subsets" as "multiple
EndpointSlices"). Can be cleaned up more later...
The slice code sorts the results slightly differently from the old
code in two cases, and it was simpler to just reorder the expectations
rather than fixing the comparison code. But other than that, the
expected results are exactly the same as before.
This exposed a bug in the EndpointSlice tracking code, which is that
we didn't properly reset the "last change time" when a slice was
deleted. (This means kube-proxy would report an erroneous value in the
"endpoint programming time" metric if a service was added/updated,
then deleted before kube-proxy processed the add/update, then later
added again.)
In the dual-stack case, iptables.NewDualStackProxier and
ipvs.NewDualStackProxier filtered the nodeport addresses values by IP
family before creating the single-stack proxiers. But in the
single-stack case, the kube-proxy startup code just passed the value
to the single-stack proxiers without validation, so they had to
re-check it themselves. Fix that.
Kube-proxy was checking that iptables supports both IPv4 and IPv6 and
falling back to single-stack if not. But it always fell back to the
primary IP family, regardless of which family iptables supported...
Fix it so that if the primary IP family isn't supported then it bails
out entirely.
PV.Spec.CSI.*SecretReference.Name should be allowed to have up to be
limited to 253 characters (DNS1123Subdomain) and not to 63 characters
(DNS1123Label), so all possible Secrets names can be used as secrets in a
PV.
This is continuation of
https://github.com/kubernetes/kubernetes/pull/108331 / Kubernetes 1.25,
which allowed updating PVs with long secret names, if the previous PV had
long secret name too. This makes sure downgrade from 1.27 to 1.26 works well
and allows PVs created in 1.27 to be updated in 1.26.
Now the long secret names are accepted during PV creation too.
