feat: add the model processor proposal

[chlins]

Issue: goharbor/harbor#21229

[vivek]

Thanks @chlins for authoring this proposal. Overall it looks good. The key aspects of the proposal make it appealing. My takeaways:

• This proposal brings AI models as first class citizen in Harbor. The user stories to use this CNAI model spec which follows OCI spec to surface AI model
• Uses existing OCI spec (artifactType and mediaType ) along with following CNAI model format https://github.com/CloudNativeAI/model-spec/blob/main/docs/spec.md
• No additional APIs needed as it leverages additions API - This is great

I left a comment regarding future model format changes and how new additions can be handled in generic way without requiring code changes. PTAL, I might be off as new to Harbor at code level, as long as we can handle such use case, its all looking good.

[vivek]

To clarify, this about displaying model file content in U, API will return the full mode file anyways, right?

[chlins]

This part needs to more detailed investigation and design, the model always be large, so I am not sure whether it should return the full model content.

[vivek]

In example below under Endpoints it specifies GET calls for license or README.md or files. If there is a new thing added to the model layer artifactType, would it continue to work or this new type will need to be added in the AI Model Processor. For example:
/additions/someNewthing would continue to work or it would needed to be added in AI Model Processor? If it does, then it can be problematic as it will need code change, upgrade of Harbor etc.

Can we leverage artifactType to be sent in an HTTP accept header. something like:

X-Accept-AI: application/vnd.cnai.model.someNewThing.v1.tar;version=1.3

There is already precedence of such header for vulnerabilities X-Accept-Vulnerabilties.

AI Model Processor can make use of this header along with value in path after additions to generically return the layer requested.

[chlins]

A more general mechanism may require a comprehensive restructuring of this part, currently each processor needs to implement the corresponding interface, and for different additions, corresponding code needs to be written for parsing, so a generic way may not be within the scope of this proposal.

[reasonerjt]

nit: the actual "signing" process is now out of the scope of Harbor, and it would be better to mention the way the artifact is signed (for example, using co-sign..) if it's part of the user stories.

[reasonerjt]

IMO in short term we only need to provide the capability of "downloading" the file. Partially showing the file will also require some change in the API, in addition to UI.

[chlins]

Sure, the "open" capability needs to do more design and API changes, btw, the "downloading" may also need the API change as it require backend return the stream for frontend. So I suggest let's put "open" & "downloading" in the phase2.

[reasonerjt]

Can we ensure backward-compatibilities in future updates? If not we need a way to manage it, for example add a switch and disable the processor by default.

[chlins]

In the current version, I think we may not need to consider compatibility issues for the time being, but starting from some future stable version, backward compatibility should be guaranteed.

[reasonerjt]

I have some questions regarding the implementation of these APIs.

In the spec it mentions the annotations are optional. So we should also clarify what to do with a model that does not provide the annotations.

Esp. for the filelist API, the spec doesn't require a 1:1 mapping between a file and a layer(It says SHOULD though), and there can be cases when the annotation org.cnai.model.filepath is not added to any or every layer, shall we also consider that?

[chlins]

Since this value is in the annotation, it might not be suitable as a MUST. Therefore, the handling in Harbor can be considered simpler: for layers with this annotation, return them; for those without, ignore them.