Decide if spin-operator should be a global or namespaced operator

[calebschoepp]

Currently the spin-operator acts globally (you can apply your SpinApps into any namespace). But, our SpinAppExecutors are namespaced (they need to be in the same namespace as your SpinApp).

We need to decide if we want the spin-operator to be a global or namespaced operator.

[endocrimes]

Global Operator + Global Executors I think would be my preference as a plan to move forwards - CRDs being global means namespaced operators are somewhat annoying to manage wrt version handling. Executors being namespaced are a little bit awkward because RuntimeClasses are global.

[endocrimes]

I think the current state of this means for launch we're doing Namespaced executors, and a plan for switching to global will be:

• Add a global resource SpinExecutor? (name tbd)
• Support both for 2 releases
• Drop the namespaced SpinAppExecutor resource

[calebschoepp]

@endocrimes would we have to change the name? Could we just bump SpinAppExecutor to v1alpha2 instead? Or in practice would we want to move version like that in lock step across all CRs?

[michelleN]

+1 to global operator and global executor. There will be folks who want to configure per namespace. We should figure out how to do that down the line if that's desirable but it'd be great if by default these were global.

@endocrimes would we have to change the name?

I'd be in favor of taking this opportunity to make the name shorter.

[calebschoepp]

It sounds to me like we're building consensus around the steps:

• Add a global resource SpinExecutor? (name tbd)
• Support both for 2 releases
• Drop the namespaced SpinAppExecutor resource

I'll leave this issue open for another day or two to give people (CC @bacongobbler) to chime in if they want with different opinions. Then if we still have consensus by then I'll close this issue and open some new issues to track the work in the steps above.

[bacongobbler]

Sounds good to me!

I don't think this work would affect spin kube - only thing from my end would be ensuring we update the docs site when this lands. I contributed a small note to the docs two weeks ago about SpinAppExecutors being namespaced per #55.

[endocrimes]

I increasingly strongly feel like SpinAppExecutor should stay namespaced, but I wouldn't necessarily be opposed to a SpinAppExecutor in the same-namespace-as-the-operator being treated as the global defaults (as much as it's a bit weird, and would be hard to debug, and not really recommended)

The executor is a combination of binding to global config RuntimeClass-es, but also things that are localized to a namespace (configuration over the way the executor binds applications), but also it's increasingly emerging as our "common to a set of applications, not necessarily a cluster" configuration point. Where many of those would be configured by application operators, not cluster operators.