allow default executor without spinappexecutor resource applied

[michelleN]

It would be nice if we could default to using containerd-shim-spin as the default executor without having to install of configure the SpinAppExecutor resource and we could use SpinAppExecutor as a means for extending to other executors as well as configuring non-default values ( ex. using a non-default name for the executor, using a non-default runtimeClassName)

We've had this convo before I believe but I still go back to wanting this experience mostly because it's a few less steps and potential errors in the quickstart workflow.

The SpinApp "simple-spinapp" is invalid: spec.executor: Invalid value: "containerd-shim-spin": executor does not exist on cluster

[radu-matei]

Would a single file installation of CRDs (#185) address this?

[endocrimes]

I'm still strongly against this - magic names lead to much more confusion over time - and makes it harder for us to debug users environments. notably it also would change behavior of existing resources when doing so, which is always regrettable when potentially accidental.

[michelleN]

Would a single file installation of CRDs (#185) address this?

The issue is the executor must live in the same namespace as the app so it's really something that needs to get installed after installing the operator bits depending on which namespace you want to install your apps in.

[calebschoepp]

It sounds like #142 would address this issue.

[jpflueger]

I'm still strongly against this - magic names lead to much more confusion over time - and makes it harder for us to debug users environments. notably it also would change behavior of existing resources when doing so, which is always regrettable when potentially accidental.

Is there a way we could support this at deploy time to work around your concerns here? Thinking that if there was an environment variable like EXECUTOR_DEFAULT_RUNTIMECLASS=wasmtime-spin-v2 set we could enable this behavior when the operator is installed.

I guess the problem I'm interested in solving is trying to have the spin-operator ready to handle SpinApps after running a helm install (or equivalent method). As we look into adding a SpinKube offering to various k8s marketplaces, some of them (AWS EKS Marketplace) don't allow things like helm hooks to apply the executor as a post-install step.

[endocrimes]

That has the same problem - iirc we already made a magic default for the executor name - having that intersect with a magic default runtime class would make understanding how your apps are running pretty difficult 😞

[chrismatteson]

I strongly believe that we need some sane defaults so "it just works" without forcing people to make choices they don't fully understand. It's great to have flexibility if people want it, but if we can't get to "here is production ready code that makes these assumptions" we will slow our adoption significantly via self-injury.