Static JSON schema for auto-complete and validation

[morri-son]

Description Write a json schema for constructor yaml (optimized for auto completion) and make it consumable through the ocm website

Done Criteria

• [ ] ...
• [ ] Code has been reviewed by other team members
• [ ] Internal technical Documentation created/updated
• [ ] New / changed code is documented
• [ ] Analysis of existing tests (Unit and Integration)
• [ ] Unit Tests created for new code or existing Unit Tests updated
• [ ] Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
• [ ] Enduser Documentation updated (if applicable)
• [ ] Successful demonstration in Review

[fabianburth]

I think it's more important to start analysing the ocm controllers (as a team effort).

Theoretically, the json schema should be integrated into the library. Thus, the json schema's should reside somewhere alongside their formal go types and should also be accessible from code (e.g. through go:embed). This way, we can establish that json schemas are also added together with each extension (thus, a new access type or a new input type) and reduce the risk of letting the schema become outdated. These individual schemas would then have to be merged in a specific manner.

But that solution would require a considerable effort. Thus, let's postpone the complete solution for now and just provide a static json schema for the component constructor files.

I've fooled around with this some time ago. If you want to pick up this task, contact me real quick.

[morri-son]

@fabianburth , can you please weigh both solutions with regards to benefits and drawbacks and estimated effort? Then we can decide if it is really the better solution to go with the static json schema.

[fabianburth]

The static schema should be doable in about 1-2 days, but since it's easy to forget, it will quickly be outdated once a new extension type is added. It's hard to estimate the complete solution. But I think it might easily take 2+ weeks.

As long as no new extension type is added, both solutions are equivalent in regards to user value.

[morri-son]

ok, that means we talk about adding 7 to 14 extension until we hit the break even. Sounds like the static schema is ok 🙂

[Skarlso]

We have a pretty much up-to-date schema file, I'll add it to the website. We can worry about it being out-of-date after we figure out how to automatically generate a nice one.

Although, I doubt we'll have something as neat as a handcrafted one. But at least something.

[morri-son]

@fabianburth @Skarlso @hilmarf @mandelsoft we also have #23 #30 #141 in place that touch things around the schema, maybe we bundle all of them together? And I also would like to ask the heretical question again: Wouldn't it make sense to skip v3 completely? I don't think that the idea of different format representations of the same content are helpful, in contrast to that I see that complicating things, making them harder to understand. I also don't think that we made OCM anything more attractive to the Kubernetes-near community just by creating a scheme that is similar to how resources in Kubernetes are defined.

[Skarlso]

Forgive me but this schema talk here is not about component descriptor, but the Configuration that a user can use to define a component yaml, isn't it?

[morri-son]

Forgive me but this schema talk here is not about component descriptor, but the Configuration that a user can use to define a component yaml, isn't it?

ah, yes, your right. Bundling here makes no sense. But, maybe it's also time to get our component descriptor schemas (or hopefully in the future just the schema :-)) updated.