Control over Storage Class for testkube jobs and testkube-container-jobs

[loorcker]

Is your feature request related to a problem? Please describe.
I wanted to set stiff storageClass name for testkube Jobs, but it sits in ArtifactRequest.StorageClass.
This is something troubling if I have preprod (different storageClass) and Prod Environment( differentStorageClass).
For now its only possible by editing chart which requires maintaining two separate charts for prod and preprod.
In Addition, I cannot use Template language to get in there to set value, by .Values.StorageClassName.

Describe the solution you'd like
It would be great to have control over such delicate matter as storageClass. As for today different users of Testkube have to be very careful to set a proper storageClass Name in test Definition on dashboard.

Describe alternatives you've considered
Thought about setting stiff values in charts of pvc-template, job-template, job-container-template. But for 2 clusters its very risky to maintain.

Additional context
I wanted simply to hide storage class from definition view, so it will not make any more trouble k8s cluster if someone decides to edit it by hand, and write the wrong storageClassName.

[vsukhin]

looks like an enterprise request to me @TheBrunoLopes @jmorante-ks

[frederikb]

This was one of the first hurdles we encountered when evaluating artifact archival. While I applaud the flexibility provided, requiring test developers to define the storage class for each and every test seems a bit too low-level, in our opinion.

We attempted to update our template to define a default storage class as a fallback, making artifactRequest.storageClassName optional. Unfortunately, this approach does not work because the codebase mandates setting this field, and without it, will not initiate scraping.

Examples:

# containerexecutor.go
if supportArtifacts && execution.ArtifactRequest != nil &&
	execution.ArtifactRequest.StorageClassName != "" {
	ids = append(ids, id+"-scraper")
}

Other locations:

Suggestion

Introduce an optional configuration parameter that specifies the default/fallback storage class to the API Server. This parameter can be set optionally via the values.yaml file when installing Testkube using its Helm chart.

The conditional checks mentioned previously can be adjusted to take this fallback storage class into account. If neither the specified storage class nor the fallback is provided, then scraping will be disabled, as was the case previously. This change ensures that the existing functionality and behavior remain stable and is aligned with other configuration options, such as those which enable overriding job templates.

What do you think, @vsukhin ?

[vsukhin]

thank you, @frederikb looks like a good idea to me and simpel to implment. I will ping for priorities @TheBrunoLopes and @jmorante-ks