search

oam-dev / spec

Open Application Model (OAM).
https://oam.dev
Other
3.03k stars 246 forks source link

Definition of componentSpec in the component JSON Schema expresses no constraints #470

Open Relequestual opened 2 years ago

Relequestual commented 2 years ago

The first definition defined in the component schema looks to be incorrect. Currently, the componentSpec defines no JSON Schema keywords, and so emposes no constrains as to what it should contain.

I suspect this is an oversight, and you just need to nest the current object inside properties.

This does suggest that you might not be testing your schemas to make sure they do what you want. It might be beneficial to do this to avoid this issue in the future.

You can use the same approach as per the official JSON Schema test suite, and probably borrow existing testing code in your language of choice as a result.

https://github.com/oam-dev/spec/blob/21d46094596318bed11f6535e96ef82af74b2232/schema/component.schema.json#L45-L87

z0r0 commented 2 years ago

In also working on this with the reporter, I suspect that the componentSpec should also have a "type" of "object" associated with it.

resouer commented 2 years ago

Thanks for reporting! My 2c is it may be way easier to generate from KubeVela's go types directly - it's where the constraints are enforced indeed.

z0r0 commented 2 years ago

Are these schemas even being used directly anymore then if they're being re-implemented within kubevela?

Relequestual commented 2 years ago

Thanks for reporting! My 2c is it may be way easier to generate from KubeVela's go types directly - it's where the constraints are enforced indeed.

Great. If you can generate them from a source of truth, that's always preferable. It's usually really hard to do that though, and tooling isn't there. You'd have to build your own solution. Yack shaving for sure.

resouer commented 2 years ago

@Relequestual Yeah, we already explored it a bit actually. For example, vela now auto-generating json schema for the schematic section of OAM entities, and then build UI forms with it. This is early stage but IMO a promising direction as the customer's dashboard are fully "pluggable", new forms become immediately ready to use whenever a new component/trait is installed in the platform.

@z0r0 KubeVela is actually the source-of-truth for the whole thing, a possible action is we could officially export the schemas from vela api to the spec repo in next release.