cloudevents
Should we target a Kubernetes Resource Model for the Discovery and Subscription APIs?
At the moment we are going down the path of custom REST APIs for the Discovery and Subscription APIs. Being part of the CNCF, we should consider the more ubiquitous APIs of Kubernetes to define these resources in a declarative way?
- [ ] Scott to make an example fork of the APIs as KRM.
This project is in the CNCF but not part of the Kubernetes project and it would severely impact the reach of CloudEvents if it were to favor one particular shape of management API.
The resulting dependencies would be such that the CloudEvents APIs would have to refer to the Kubernetes API definitions as foundational and this would, in effect, turn CloudEvents into a dependent sub-project of Kubernetes since all changes in the respective definitions in Kubernetes would also change the CloudEvents API and the CloudEvents API could not evolve in any way outside of the ruleset and boundaries defined by Kubernetes.
It would also make CloudEvents problematic to use with services that are at "Ring Zero" of Kubernetes itself and that can't take a dependency on Kubernetes or any particular version of it. For instance, etcd and Prometheus have plain, bespoke REST APIs.
I don't think it has to be an either/or thing. I believe other projects use Kubernetes style yaml apis but use their own api implementations that accept them. So if you were to implement on top of Kubernetes, you could load the yaml in as a Custom Resource, but that isn't a requirement. Also, Declarative apis in general have proven to be quite useful. So even if not done as a Kubernetes api, it being declarative should be considered IMO.
To me it would feel odd to use Kube YAML but then use some other API - I'd prefer to either go "full Kube" or "not at all". I think a half-way solution will either confuse or annoy people.
As to whether we should use Kube or not... personally, I'd vote 'no' because I wouldn't want to link our specs to one specific implementation choice.
I'm not against a declarative API though.
I'm going to propose that we close this issue on this week's call. If you'd like to advocate keeping it open please speak up (here or on the call).