Review and Comments: 03-component-repository.md

[jensh007]

Component Repository Specification

... A facade/proxy API layer on top of the backend, implementing the upload, fetch and delete methods according to the requirements of this specification. This could be a Go/Python client API, some http server...

Not sure about this wording and the diagram
We have to define a method to (remotely) access component-descriptors. Instead of language bindings we could specify a remote protocol and storage layout. Language bindings would have to be defined for many different languages and continuously to be maintained for new languages. This is a lot of effort. Instead we could define protocols on top of existing storage layers (OCI, S3, etc) with a mapping from the component model to the model of the storage layer (OCI layer, S3 object names, file and folder names).

Clearly distinguish between an abstract functional model and a concrete binding to a storage backends. See also https://github.com/gardener/ocm-spec/blob/main/doc/proposal/in-progress/05-component-repository-oci.md

Perhaps move this to a separate part of the spec, an appendix or even a separate spec.

It should become clear what the interface for interoperability is and what are implementation details.

[achimweigel]

@jensh007 I'm not sure if I really understand all your points. In my opinion, most potential users of the OCM spec do not want to implement a component repository but using it for handling with component descriptors in some tools, pipelines etc. Such a user would like to have a uniform, simple and elegant API (in his preferred language or protocol), which builds an abstraction on top of the different component repository implementation. Therefore, I think the definition of such APIs should be one central part of the spec.

I fear, if there are e.g. different http protocols for the different storage layers, a potential user would be much more reluctant to use OCM. She/he will not develop and maintain different implementations for different component repo implementations. I would even say, that it is very important to hide as much of the storage layer as possible. At least for me, all this OCI stuff is such a technical burden and as an end user, I do not want to see the internal storage layout of a component descriptor in an OCI registry in an API.

With respect to different language bindings, I think it would be a good idea to specify an API for at least one language (e.g. go) as an example, e.g. in an appendix of the spec. Bindings for other languages could be developed later by whoever it needs and need not be part of the core specification.

What is completely unclear for me, what of the current component repository on top of an OCI repository and of the OCM CLI should become part of the OCM spec. I could even imagine, that nothing of this implementation is part of the core spec. For me this is one technical realisation, we should describe in technical/architectural documents but not in the spec itself. These documents might also include all required information, such that others could provide their component repo such that is could be also used with the OCM CLI.

[achimweigel]

With respect to define specific storage layouts for e.g. OCI or S3 backends(https://github.com/gardener/ocm-spec/blob/main/doc/proposal/in-progress/05-component-repository-oci.md) I try to sketch why we need this - not sure if this is correct:

Storage specific layouts provide different developers an interoperable way to implement libs for different programming languages/protocols exposing e.g. OCI registries as a component repository. For example, they could provide a java-lib and a golang-lib such that clients could access the same OCI backend with either the java of the golang lib, which is only possible, because both store the data (component descriptors, local blobs) the same way.

We should clarify:

• Why this is the preferred way to go and just providing a definitions of a logical API and some protocol/language bindings is not sufficient (backend provider will not expose their stores as component repos ...)?
• Are such layouts definitions for different backends part of the OCM spec or more technical extensions? If they become part of the spec, how is the process to add layouts for additional backend types and how to handle alternative potentially improved layouts for a particular backend type.
• We should be carefully distinct the different types of interoperability in the context of OCM. For many users, it is more important that it is possible to use a lib in a particular language to store data in many different backend types. This is a totally different kind of interoperability.

[TieChuiZhang]

有事电联137********