Open autodidaddict opened 3 years ago
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!
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".
Per the spec:
And then further down, we see the list of core workloads in the specification:
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, orWASI
modules orWebAssembly
modules orcron
jobs orbash
scripts or even non-containerizedlambdas
? Those runtimes shouldn't have to support (or pretend to support) containerized workloads.