Ensure CRDs are installed first

[sacha-l]

Ran into this error when launching my zombienet with: zombienet -p kubernetes spawn examples/0001-small-network.toml

Error: Command failed with exit code 1: kubectl --kubeconfig /Users/sachalansky/.kube/config --namespace zombie-539f4cbf57c9d9b5e839e923a903d9df apply -f -
error: resource mapping not found for name: "cleaner-zombie-539f4cbf57c9d9b5e839e923a903d9df" namespace: "" from "STDIN": no matches for kind "CronJob" in version "batch/v1beta1"
ensure CRDs are installed first
    at makeError (/Users/sachalansky/Documents/GitHub/Zombienet/zombienet/node_modules/execa/lib/error.js:60:11)
    at handlePromise (/Users/sachalansky/Documents/GitHub/Zombienet/zombienet/node_modules/execa/index.js:118:26)

The fix was to run it using the -m flag.

[Gioyik]

@pepoviola @wirednkod I would like to work on this one, could you please provide me more information about what needs to be accomplished here?

[pepoviola]

Hi @Gioyik, thanks for your contribution. As context of this task, for k8s provider we create a cronjob as cleanup-timer to prevent leaking resources if the user loose the connection to the k8s cluster. But the cluster needs support for that configuration (CronJob) and some dev clusters like kind or the one that is shipped with Docker desktop may not support this. So, we should check if cronjobs are supported before trying to configure it.

Ping me if you have questions, thanks!!

[Gioyik]

I am retaking this one. @pepoviola this is where I see the creation of the cronjob https://github.com/paritytech/zombienet/blob/main/javascript/packages/orchestrator/src/providers/k8s/kubeClient.ts#L506, so I will research how to check if is available, any extra info about what should I check it's always good.

Another fact is, how does behave today when the cluster doesn't have support for that configuration, does it fail or stops with the stack trace? How can I test the scenario, is there anything I could trigger to get a reproducible scenario to test against my changes?

[l0r1s]

@pepoviola What is the expected behavior in the case where some CRD is not supported by the cluster ? Should we throw a fatal error ? Should we disable the not supported CRD ? Should we check for local cluster and ignore in that case and throw if non local cluster ?

[pepoviola]

@pepoviola What is the expected behavior in the case where some CRD is not supported by the cluster ? Should we throw a fatal error ? Should we disable the not supported CRD ? Should we check for local cluster and ignore in that case and throw if non local cluster ?

Hi @l0r1s, in this particular case we should not trying to create the resource if the CRD is not supported.

Thanks!!

[pepoviola]

Ping @l0r1s, is this still todo? Thx!

[l0r1s]

@pepoviola Yes it is