Add support for volume and volume mounts for runners

[andrei-trandafir]

Currently there is no way to add different volume mounts to the runner pod, other than the default one that is created from the script spec. This PR adds support volumes and volume mounts.

The scenario we're aiming to utilise these in is when we're fetching the k6 script(s) and other artifacts from an external source (i.e. S3) through init containers, and copying them to the main containers using a Volume of type EmptyDir.

Closes #250

[yorugac]

@andrei-trandafir I have a change request: could you please remove changes to Makefile and instead add a new file, smth like e2e/test-initcontainer-volumes.yaml, which uses this new fields?

Otherwise, the changes seem OK to me and thanks for adding the Go test 🙂

[andrei-trandafir]

Thanks for the review @yorugac , i've reverted the Makefile changes and added a new sample k6 file in e2e.

[yorugac]

@andrei-trandafir thanks for updates! The yaml test needs a very small update: it fails at the moment, please see the comment.

And one more thing. When trying to deploy from your branch as is, I hit an interesting error about byte limit:

The CustomResourceDefinition "k6s.k6.io" is invalid: metadata.annotations: Too long: must have at most 262144 bytes

It seems it can be resolved by adding parameter crd:maxDescLen=0 in Makefile. But since you didn't add this parameter as part of PR, I wonder have you encountered this error during your testing?

[andrei-trandafir]

@yorugac thanks for spotting the issue. I probably copied the wrong file 😅

Regards the CRD install, I believe I encountered the issue once and didn't keep the solution in the Makefile in the end.
The way I solved it was by adding the following flag to the kubectl apply in the deploy command in the Makefile:

--server-side=true

This avoids using the "last-applied-configuration" annotation from what I understand.

[yorugac]

OK, I see. Actually, --server-side=true seems to work only on clean slate, i.e. without existing k6-operator deployment. Otherwise, I get these errors:

error: Apply failed with 9 conflicts: conflicts with "kubectl-client-side-apply" using apiextensions.k8s.io/v1beta1:
- .spec.validation.openAPIV3Schema.properties.spec.properties.initializer.properties.initContainers.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.initializer.properties.volumeMounts.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.initializer.properties.volumes.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.runner.properties.initContainers.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.runner.properties.volumeMounts.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.runner.properties.volumes.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.starter.properties.initContainers.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.starter.properties.volumeMounts.items
- .spec.validation.openAPIV3Schema.properties.spec.properties.starter.properties.volumes.items

But also, for 'cleaner' solution I think it's better to change make manifests with crd:maxDescLen=0 and not make deploy with --server-side=true: so that there's an impact only on manifest generation during development and not on the bundle generation during deployments and releases. So, could you please add that crd:maxDescLen=0 to make manifests as well? Assuming that option works in your setup as well 🙂

[andrei-trandafir]

Added and tested the changes. Everything seems in order 👍🏼
Thanks @yorugac

[yorugac]

LGTM! Seems to work AFAIS 👍
Thanks for the changes 😄