Consider lifting mandatory implementation requirement for ContainerizedWorkload

[autodidaddict]

Per the spec:

OAM implementations MUST implement all core workloads as defined in this specification.

And then further down, we see the list of core workloads in the specification:

The following core workloads are defined in the OAM specification.
Containerized Workload

This makes it seem like any OAM implementation (and I'm assuming there might eventually be some kind of list of "certified" or "accepted" OAM runtimes) must support the ability to manage containerized workloads. If OAM is truly open and truly infrastructure agnostic, then I don't believe it should mandate that all implementing runtimes must support a containerized workload.

I can see having the spec for ContainerizedWorkflow be a part of the official OAM spec, as that metadata is broad and universal enough that it should come with the core... but what about mini/micro OAM runtimes that might manage different kinds of workloads--raw processes, or WASI modules or WebAssembly modules or cron jobs or bash scripts or even non-containerized lambdas? Those runtimes shouldn't have to support (or pretend to support) containerized workloads.

[ryanzhang-oss]

The reason that we would like all OAM runtimes to support ContainerizedWorkload is to have a unified way to express an application across different OAM platforms. You are more than welcome to bring this up in our upcoming OAM community meeting next week!

[resouer]

The ContainerizedWorkload schema assumes OCI image as the way to package artifacts, it has no assumption that the implementation should be Linux container. But I agree it's also a valid point that artifacts could be WebAssembly modules or a simple zip etc. Worth a further discussion indeed, if we could introduce a more generic workload schema, we could downgrade ContainerizedWorkload to standard.oam.dev. Or, we simply make the requirement "if applicable".