* apiserver/storage/continue: intro PrepareContinueToken
PrepareContinueToken prepares optional
parameters for retrieving additional results for a paginated request.
This function sets up parameters that a client can use to fetch the remaining results
from the server if they are available.
* apiserver/storage/etcd3: refactor to use PrepareContinueToken
This adds a generic implementation of a clientset, and uses it to
replace the template code in generated clientsets for the default
methods. The templates are preserved as-is (or as close as they can
be) for use in extensions, whether for resources or subresources.
Clientsets with no extensions are reduced to their main getter, their
interface, their specific struct, and their constructor. All method
implementations are provided by the generic implementation. The
dedicated interface is preserved so that each clientset can have its
own set of methods, and the dedicated struct is preserved to allow
extensions and expansions to be defined where necessary.
Instead of handling the variants (with/without namespace, list, apply)
with a complex sequence of if statements, build up an index into an
array containing the various declarations.
The namespaced/non-namespaced distinction matters in the code
templates, but not in the methods themselves, so drop all the
non-namespaced variants and pass in "" explicitly.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Several pods sharing the same claim is not common, but can be useful and thus
should get tested.
Before, createPods and createAny operations were not able to do this because
each generated object was the same. What we need are different, predictable
names of the claims (from createAny) and different references to those in the
pods (from createPods). Now text/template processing with the index number of
the pod respectively claim as input is used to inject these varying fields. A
"div" function is needed to use the same claim in several different pods.
While at it, some existing test cases get cleaned up a bit (removal of
incorrect comments, adding comments for testing with queuing hints).
v1beta3.ClusterConfiguration.APIServer.TimeoutForControlPlane
must be migrated to {Init|Join}Configuration.Timeouts.
.ControlPlaneComponentHealthCheck.
To achieve this sort of cross-Kind migration do the following:
- Use a temporary, thread-safe variable in timeoututils.go
- Make the order of GVKs in documentMapToInitConfiguration
deterministic.
Flags for kubeadm init such as --apiserver-extra-args prior
to v1beta4 used a map[string]string for pflag.Value storage. This no
longer works since v1beta4 extra args are a slice of Arg.
Add a new flag type argSlice and implement a solution for
parsing these flags.
At the same time deprecate these flags and show a warning
that users should use config.
Instead of defaulting ExtraEnvs for CP components to an empty
slice when converting from/to v1beta3 keep it nil.
This allows for expecting a nil value in the internal
config, similarly to ExtraArgs.
- Include some more examples related to v1beta4 in the doc.go.
- Fix some typos in v1beta4 field comments.
- Add missing JSON tag for UpgradeConfiguration.Apply.SkipPhases.
Extension methods on the main resource are supported by client-gen,
but unused in k/k; to detect regressions in future changes to
client-gen, add a minimal example (this should be turned into a proper
test).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
This will be used when generifying client-go: applying
ApplyConfigurations requires extracting their name, which is currently
done by accessing the corresponding public field directly; but that
can't be done with interfaces, which is what have to be used with
generics.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
e2e_node test depend on very specific shared state (node state).
Pod leakages between tests oftentimes cause the test preconditions
to be silently corrupted, causing hard to debug CI failures.
Use the new facility to annotate pods with test owner (= the
test code which created the test) to help debug these failures.
For more context, please check the conversation in #123468
Signed-off-by: Francesco Romani <fromani@redhat.com>
e2e_node test depend on very specific shared state (node state).
Pod leakages between tests oftentimes cause the test preconditions
to be silently corrupted, causing hard to debug CI failures.
We add the option to add an annotation to pods which records
the code line (source code:line) which triggered the pod creation,
so it becomes easier to track which test needs better cleanup.
The relevant e2e framework code is used in all the e2e suites,
so to minimize any unwanted consequences we make the feature
opt-in, planning to enable it initially (and likely only)
in the e2e_node tests.
Signed-off-by: Francesco Romani <fromani@redhat.com>
The claim parameter key didn't include the namespace of the claim. In the case
where two namespaces used the exact same parameter reference, the "too many
generated parameters" case got triggered incorrectly and lookup could have
returned an object from the wrong namespace.
Found while running the E2E tests in parallel:
message: 'running PreFilter plugin "DynamicResources": multiple generated claim
parameters for ConfigMap. dra-8794/parameters-3 found: [dra-4729/parameters-4
dra-7328/parameters-4 dra-8794/parameters-4 dra-3402/parameters-4 dra-6156/parameters-4
dra-1839/parameters-4 dra-7434/parameters-4 dra-6504/parameters-4]'
