spec
spec copied to clipboard
oam-dev
Could the OAM Container be a subset of the Kubernetes Container?
Currently OAM defines the schema for a Container that is very similar to, but not exactly the same as the Kubernetes Container. The OAM spec probably cannot use the exact Kubernetes Container type, because it includes several concepts that don't exist in OAM (e.g. reading env vars from secrets and configmaps). However, if we made the OAM Container schema a strict subset of the Kubernetes Container schema and also allows runtimes to support additional, optional fields per https://github.com/oam-dev/spec/issues/324, then OAM runtimes that used the Kubernetes API server could simply use the existing Kubernetes Container type rather than redefining it and writing logic to translate an OAM Container into a Kubernetes Container.
As a reference to what translation of the current OAM spec Container to a k8s Container looks like, see https://github.com/hasheddan/stack-oam-kubernetes-remote/blob/f779c28889dfcbfdbfe67bdc0e2411bccf074b98/pkg/controller/containerizedworkload/containerizedworkload.go#L88
I can see how it would bring convenience to the Crossplane implementation. Because today we don't have an OAM spec implementation that is using another orchestrator, it is tempting to just match the Kubernetes spec.
My biggest concern would be making the OAM spec tightly coupled with Kubernetes spec (either consciously or inferred by the community). It would have long term consequences in support, like OAM spec playing catch up with Kubernetes spec.
My biggest concern would be making the OAM spec tightly coupled with Kubernetes spec (either consciously or inferred by the community). It would have long term consequences in support, like OAM spec playing catch up with Kubernetes spec.
That makes sense. Though that said, Kubernetes has very strict rules about breaking changes for their API types like Container. If we made the OAM Container either exactly a Kubernetes v1 Container or a strict subset of a Kubernetes v1 Container we would always be able to very easily translate an OAM container into a Kubernetes v1 Container. We would be guaranteed that Kubernetes would not make breaking changes to the v1 Container schema.
I'm curious how conscious the decision was to make the current OAM container schema different from Kubernetes. The schemas seem to be ~80% identical - OAM Container is obviously heavily influenced by the concepts and schema of a Kubernetes container. Why is the last ~20% different? Do we really feel like we've improved the way one models a Container compared to Kubernetes, or are we just differing from Kubernetes for the sake of differing from Kubernetes?
In addition, if there was any part of the Kubernetes API that we mirrored, if it did somehow change in the future the worst case scenario is that we end up in the situation we are currently in where we are translating the OAM spec to the Kubernetes API.
I have some concerns about making **the OAM Container schema a strict subset of the Kubernetes Container schema **.
- OAM still don't have some kubernetes concepts like
Secret/Configmap, I'm not sure if it's possible to have a clean separation for OAM subset. - Some fields of Kubernetes Container schema should be moved to traits in OAM.
- If OAM container is a strict subset of a Kubernetes v1 Container, how could we extend OAM container spec in the future?
OAM still don't have some kubernetes concepts like Secret/Configmap, I'm not sure if it's possible to have a clean separation for OAM subset.
I imagine we'd omit any fields relating to these concepts from the subset.
Some fields of Kubernetes Container schema should be moved to traits in OAM.
As above, I imagine we'd omit these concepts from the subset and use traits instead.
If OAM container is a strict subset of a Kubernetes v1 Container, how could we extend OAM container spec in the future?
This is a valid point - we'd need to be relatively confident that we weren't going to add fields to our container that weren't supported by a Kubernetes container. Perhaps we should worry about this if and when we face it? I suspect we'll need to make breaking changes to the container schema when we want to support additional container platforms, which would require bumping the API version for container anyhow.
The short answer is yes if we are confident that we won't add other fields not in K8s containerSpec.
Some related issues:
https://github.com/crossplane/addon-oam-kubernetes-remote/issues/5 https://github.com/oam-dev/spec/issues/313 https://github.com/oam-dev/spec/issues/308
My biggest concern would be making the OAM spec tightly coupled with Kubernetes spec (either consciously or inferred by the community). It would have long term consequences in support, like OAM spec playing catch up with Kubernetes spec.
I agree with this and also have concerns around messaging in the sense that folks will have more and more feeling it's k8s only (while it's obviously not, but doesn't help)
I agree with this and also have concerns around messaging in the sense that folks will have more and more feeling it's k8s only (while it's obviously not, but doesn't help)
Note that we are defining a container workload and K8s is the de facto standard for container orchestration. I don't think the messaging is a concern unless Swarm/Mesos folks raise hands here 😄 .
For tech part, allow me to summarize a bit:
- it's a subset, simple and easy to learn and use - end users are happy
- it saves time from reinventing wheels, we will lock the reference to a specific K8s API version and it's never our intention to track the update - OAM maintainers are happy
- K8s implementers are happy
- it even benefits non-k8s implementers since they can now import tons of existing libs e.g. Go types and Rust types instead of create everything from scratch
Unless there are objections from above 4 interest parties, it seems a many-win decision.
Of course, the maintainers are always very cautions on the narrative and wording in the spec, runtime agnostic is definitely the goal.