Background
We've added a .spec.podTemplate field to the PrivateLoadZone CRD in v1.3.0. It allows setting a few fields that will be applied to all TestRuns and pods started by that PrivateLoadZone.
The PrivateLoadZone CRD embeds an actual Kubernetes PodTemplate object, but the CRD itself is generated with a validation patch that allows only a limited set of fields.
What
This addition was the first step towards us adopting PodTemplate everywhere. We intend to gradually relax those validation restrictions in the patch, as we get ready to support more fields. The same goes for the TestRun CRD: the PrivateLoadZone CRD is built on top of TestRun and it cannot be fully "relaxed" without changing TestRun in turn.
Why
- We observed a clear pattern of repetitive additions of fields to the
TestRun CRD as people need greater flexibility to configure their workloads according to their use case.
- The pace of additions tapered off a bit recently (for
TestRun), but the Pod's definition changes with time as well.
- Using
PodTemplate allows us to unlock all configuration options at once and simplify the current process.
- The
PrivateLoadZone CRD supports only a subset of what is provided by the TestRun CRD, and we might need to go through the same repetitive process for it.
- k6-operator needs to control only a small number of fields and does not "care" about other fields, so most such additions are simple pass-throughs.
- Using
PodTemplate will result in simpler code (once it's fully utilized in TestRun) and let Kubernetes-native validation do the rest.
There are some drawbacks to this decision too, for example, the need to find suitable workarounds for containers.
Scope
Of course, this is a rather large undertaking so it'll take some time and multiple steps. At least for the TestRun CRD, this will be a breaking change. This issue is meant to be an umbrella for the switch as a whole: additional issues and PRs can be added as needed.
If there are strong opinions on this topic, please do share in the comments!
Background
We've added a
.spec.podTemplatefield to thePrivateLoadZoneCRD in v1.3.0. It allows setting a few fields that will be applied to allTestRuns and pods started by thatPrivateLoadZone.The
PrivateLoadZoneCRD embeds an actual KubernetesPodTemplateobject, but the CRD itself is generated with a validation patch that allows only a limited set of fields.What
This addition was the first step towards us adopting
PodTemplateeverywhere. We intend to gradually relax those validation restrictions in the patch, as we get ready to support more fields. The same goes for theTestRunCRD: thePrivateLoadZoneCRD is built on top ofTestRunand it cannot be fully "relaxed" without changingTestRunin turn.Why
TestRunCRD as people need greater flexibility to configure their workloads according to their use case.TestRun), but the Pod's definition changes with time as well.PodTemplateallows us to unlock all configuration options at once and simplify the current process.PrivateLoadZoneCRD supports only a subset of what is provided by theTestRunCRD, and we might need to go through the same repetitive process for it.PodTemplatewill result in simpler code (once it's fully utilized inTestRun) and let Kubernetes-native validation do the rest.There are some drawbacks to this decision too, for example, the need to find suitable workarounds for
containers.Scope
Of course, this is a rather large undertaking so it'll take some time and multiple steps. At least for the
TestRunCRD, this will be a breaking change. This issue is meant to be an umbrella for the switch as a whole: additional issues and PRs can be added as needed.If there are strong opinions on this topic, please do share in the comments!