Ideas for test extensions improvements

[fabriziopandini]

While developing #7288 we collected some ideas for improving test extensions; I'm reporting them here in order to keep track/ trigger discussion on next steps

• ✨ Support IPAM and runtime extension providers #7288 (comment) Rename test extension to something that avoids us to use "runtime-extension-test-extension" (or make test-test-extension)
• ✨ Support IPAM and runtime extension providers #7288 (comment) Audit the config folder to evaluate better consistency with other providers
• ✨ Support IPAM and runtime extension providers #7288 (comment) Rethink defaults for lifecycle hooks/if to add a way for customizing them
• Add a lib func for validating received variables are of the expected types
• Add a lib func for converting complex variables into go structs and/or other basic types.
• Add a lib options allowing to set patchFormat for single patches only.
• Introduce a notion of ordering for templates passed to GeneratePatches (or processed when walking templates)

/area runtime-sdk
/kind feature

[fabriziopandini]

Note, point 3 of the above list can be addressed via #7562; most specifically, we can make the test extension to not block by default, unless a specific setting exists.
This setting can be by our E2E test framework machinery (but won't block developers using the same templates with tilt)

[fabriziopandini]

/triage accepted

[sbueringer]

Add a lib func for converting complex variables into go structs and/or other basic types.

I think in combination with variable discovery this can be more. Essentially treat variables like our regular API types:

1. define complex variables as Go types
2. and then leverage the Go types either:
   • to provide a util func to convert variables into those go types or
   • already pass the converted variable Go structs into the handler (cf. how we get the objects passed into a regular mutating/validating webhook today)
3. generate corresponding schema code via openapi gen
4. provide a util func to implement variable discovery based on this generated code
   • Note: we have to convert the generated schema code to the Cluster API schema types

3 + 4 only make sense in combination with variable discovery. 1 + 2 would make already sense today.

Theoratically 3. + a util which produces the variable schema as YAML would also make sense already today without discovery.

We should also allow type-safe access to builtin variables.

[fabriziopandini]

/close
we are reconsidering those ideas while working for implementing support for variable discovery #6901

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

/close
we are reconsidering those ideas while working for implementing support for variable discovery #6901

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.