OAM spec 0.4.0 release planning

[hongchaodeng]

We are actively developing KubeVela, and include many new updates to the application model. But we haven't updated the spec yet in a couple of months. We need to include updates from KubeVela into the spec. But before this we need to address the following questions:

• What's the relationship between OAM spec and KubeVela?
• What's the future direction for OAM spec?
• How should we update the OAM spec next?

Some background: Currently the maintainer team behind OAM spec and KubeVela are the same. Usually the development of the KubeVela project that users can use goes faster than defining the official model. Thus we update the API in KubeVela first. But when it is more stable, we will include the updates back into the API model.

Here are the official answers to above questions:

• OAM spec is the KubeVela official API model.
• OAM spec will include updates from KubeVela periodically.
• We will update the spec to include the latest change in KubeVela. Additionally, we will reflect the above two points in the spec.

More specific actions:

• To Add
  • The workflow and Policy API
• To Update
  • The overview, the architecture, and the Application API needs to be updated.
  • README needs to be updated w.r.t. the releases section.
• To remove
  • 4.workload_types.md: This is deprecated and we prioritize to use ComponentDefinition.
  • 5.application_scopes.md: We are deprecating this in favor of Policy.
  • core/, standard/, extend: We already have included these in KubeVela repo. There are more well defined workloads/traits there. We are not going to keep this in the spec repo.
  • schema/: the schema can be generated from KubeVela go APIs.
  • design/: moving this to KubeVela

[dhiguero]

Hi,

Thanks for the clarification, but I would like to express my disagreement with this proposal. I personally try to be involved in the spec area of OAM and my understanding of both projects is quite different than the aforementioned one. I think this is the type of discussion that should be addressed in the community calls, but it seems that this is not a proposal but a decision that has already being taken.

I think the OAM spec goes beyond the scope of Kubevela since Kubevela is the Kubernetes runtime of OAM, but OAM itself is and should be Kubernetes agnostic. For example, somebody may be working on a docker-compose runtime for OAM that takes OAM files as input and launches containers managed by docker. That runtime will use the spec to determine what to implement.

I think that from the point of view of the community there is little information about the decisions of what features are to be introduced in Kubevela. I think this approach works if Kubevela is an implementation of OAM for Kubernetes with the addition of some extensions, but I do not feel that OAM must contain and reflect all Kubevela features.

[resouer]

@dhiguero (... and all other maintainers). I am not the decision maker, but would like to step in to echo some of the ideas in this proposal (and add some other inputs).

TL;DR: The next version of OAM will need to be shipped in the form of a workable platform rather than spec docs. The OAM maintainers, not community users/implementors, should be responsible for doing the dirty work to make OAM usable.

As co-creator of this model, one lesson we learned from the past 2 years is: we should not have created a "spec only" project. A spec is light-weighted to maintain, can gain a lot of attention, but it can not solve real problems of users. We've seen the devils are all in implementation details and this soon becomes a blocker for anyone to ship a workable production level OAM platform w/o huge platform engineering effort. I believe this is against the goal of OAM which intends to make user's life easier.

At the meantime, during past 6 months of releasing KubeVela as the first production level OAM platform, the momentum of the model begin to show up rapidly as we expected (see: Who is using OAM/KubeVela). Just FYI, KubeVela is NOT a/the OAM k8s runtime. It is an app delivery & mgmt control plane with the goal of simplifying developer's life on top of any runtime infra ranging from K8s, cloud to edge. a.k.a it is designed to be an OAM platform since day 0 with goal to promote the idea in form of a workable system, and now it's proven to be the better path.

Hence, I agree with the proposal of focusing the whole idea to the platform itself and solving user pain points with the model, rather than maintaining a "spec only project" and expecting someone else to do the implementation, this won't work.

Q: Why not just deprecate OAM spec and maintain KubeVela only?

OAM the model is how KubeVela attempt to solve user's problem since the very beginning: give them a higher level abstraction. It is the soul of the platform.

And with the adoption of KubeVela grow, there're already interests show up to implement this model in some unique envs, and we definitely encourage this. This decision is not even "k8s or not" related - if a user feel they have to implement OAM on their own k8s infra, they can do it. If there's any contents in the model that makes a user feel hard to implement or too "k8s specific", we're happy to remove it. Of course, before all these actions, we'd like to check why KubeVela can not be applied and fix this by any means. For existing implementations that are not KubeVela, we'd like to help to upgrade, or if it's impossible, we can just leave them as community implementations for specific model versions and community partnership can still built based on this.

But all of these intents won't change the fact and direction that we (as OAM maintainers) will maintain OAM, the model, in the form of a workable platform, instead of a set of spec docs. If we feel KubeVela is the wrong platform to do this, I am eager to know what's the right one (and why we can not achieve same goal in KubeVela).

Issues need to be fixed

• KubeVela need to be improved to make it possible and 100% transparent for anyone to design and evolve the model without digging too much into the details of the platform.
  • We need labels and mechanisms to help OAM maintainers to focus on the model layer without bothering with model implementation (CUE) and runtime capabilities (e.g. rollout controller).
  • All OAM maintainers should be automatically inherited as KubeVela maintainers (at least for model layer) and have access to the project.
  • Formal community partnerships should be established around the model and the platform.
• We will need to publish/upgrade the model documentation to this repo per KubeVela releases and a process to promote new/updated model entities from KubeVela (experimenting first, get user feedback, and then promote to model docs)
  • Users of KubeVela will check this repo to learn about this model in detail and grab the ideas behind the platform. But in most cases, they actually focus on how to use the model.
• I would expect the model itself will change in very low frequency, so the process should be light-weighted.

[hongchaodeng]

Hi @dhiguero . Sorry for the late response. I got a cold and not active recently.

We take your feedback and the entire community seriously. Your voice is important to us. We believe that being neutral and open is the key to the success of the whole community.

As a result. We will keep the neutrality of the spec and not couple it to any implementation (e.g. KubeVela). We will keep evolving the spec taking feedback from all the users and vendors including KubeVela, Napptive, etc.

Thanks again for your feedback!