`NodeReachable`, `NodeLive`, `NodeSchedulable`, and `NodeRunnable` are mentioned
as "built-in set of conditions" but some of them do not exist in the current API.
Updated `pkgs/apis/core/types.go` too for consistency.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
With a dynamic client and a rest mapper it is possible to load arbitrary YAML
files and create the object defined by it. This is simpler than adding specific
Go code for each supported type.
Because the version now matters, the incorrect version in the DRA YAMLs were
found and fixed.
ktesting.TContext combines several different interfaces. This makes the code
simpler because less parameters need to be passed around.
An intentional side effect is that the apiextensions client interface becomes
available, which makes it possible to use CRDs. This will be needed for future
DRA tests.
Support for CRDs depends on starting the apiserver via
k8s.io/kubernetes/cmd/kube-apiserver/app/testing because only that enables the
CRD extensions. As discussed on Slack, the long-term goal is to replace the
in-tree StartTestServer with the one in staging, so this is going in the right
direction.
The new TContext interface combines a normal context and the testing interface,
then adds some helper methods. The context gets canceled when the test is done,
but that can also be requested earlier via Cancel.
The intended usage is to pass a single `tCtx ktesting.TContext` parameter
around in all helper functions that get called by a unit or integration test.
Logging is also more useful: Log[f] and Fatal[f] output is prefixed with
"[FATAL] ERROR: " to make it stand out more from regular log output.
If this approach turns out to be useful, it could be extended further (for
example, with a per-test timeout) and might get moved to a staging repository
to enable usage of it in other staging repositories.
To allow other implementations besides testing.T and testing.B, a custom
ktesting.TB interface gets defined with the methods expected from the
actual implementation. One such implementation can be ginkgo.GinkgoT().
Inline the LoadBalancerSourceRanges parsing to make it more obvious
what it's requiring (and more importantly, *not* requiring), and
change it to use IsValidCIDR as well.
In preparation for rewriting LoadBalancerSourceRanges validation,
add/update the existing unit tests to cover some of the more exciting
edge cases of the existing validation code:
- The values in service.Spec.LoadBalancerSourceRanges are allowed to
have arbitrary whitespace around them.
- The annotation must be unset for non-LoadBalancer services, but
for LoadBalancer services, "set but empty" and "whitespace-only"
are treated the same as "unset".
- The annotation value is only validated if the field is not set.
Also fix some of the existing tests to be more precise about what they
are testing.
Also fix the CIDR values to actually be valid. Sigh.
Do an extra "add+delete" once to ensure all previous base chains in the
table will be recreated. Otherwise, altering properties (e.g. priority)
of these chains would fail the transaction.
Signed-off-by: Quan Tian <qtian@vmware.com>
Move apivalidation.ValidateCIDR to apimachinery, and rename it and
change its return value to match the other functions.
Also, add unit tests.
(Also, while updating NetworkPolicy validation for the API change, fix
a variable name that implied that IPBlock.Except[] is IP-valued rather
than CIDR-valued.)
During initialization `kubeadm init` creates kubelet.conf with
specified name and during finalize phase validates that
this kubeconfig is not corrupted by checking for presence of specific
authinfo
However:
* kubelet doesn't require a specific name for this context
* in external CA mode this kubeconfig can be created outside of
`kubeadm init`
This change updates kubeadm finalize stage to avoid overly strict
context check.
