enable standalone artifacts

[isinyaaa]

Fixes: #231

Description

To undo some confusion around opendatahub-io/model-registry-bf4-kf#289 and re-enable standalone artifact support on both the /model_artifacts endpoint and the go core API.

TODO:

• Test standalone artifacts through REST API (via Python)
• Test late binding of standalone artifacts to model versions (in Go and via REST)
• Update REST response status code

How Has This Been Tested?

Merge criteria:

• All the commits have been signed-off (To pass the DCO check)

• The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work.
• Code changes follow the kubeflow contribution guidelines.

If you have UI changes

• The developer has added tests or explained why testing cannot be added.
• Included any necessary screenshots or gifs if it was a UI change.
• Verify that UI/UX changes conform the UX guidelines for Kubeflow.

[tarilabs]

the PR description mentions:

TODO:

Test standalone artifacts through REST API (via Python)
Test late binding of standalone artifacts to model versions (in Go and via REST)

as not yet fully done? 🤔

Also, before merging this PR, I would suggest checking for non-regression by also making use of the container image in a MR Deployment and check with the UI. (only after we're aligned on lgtm for this PR).

[tarilabs]

thank you for walking through the changes together @isinyaaa ,

well noted the modifications in fdd0209 are needed so that the POST modelversion/../artifact start to behave in upsert fashion

while none of the "base resource" are used in payload for std POST or PATCH, so the modification from that commit is compatible

nor impose any change on the goverter generated code

[tarilabs]

/lgtm

I'd appreciate as discussed if this modifications can be tested by producing a container image based on this PR, and making sure the basic UI screens still work as intended. I expect they should, given only 1 endpoint is changing semantic to become upsert, but given all the moving pieces, I'd rather be safe than sorry in this sprint. cc @isinyaaa @Al-Pragliola wdyt?

[isinyaaa]

Before:

After:

Looks fine to me. And seems to be working the same.

[Al-Pragliola]

/lgtm

[google-oss-prow]

@Al-Pragliola: changing LGTM is restricted to collaborators

In response to this:

/lgtm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tarilabs]

thank you @isinyaaa for all the changes, the discussions for clarifications, and making a smoke-test with the deployed UI

/lgtm

as previously discussed and

/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Al-Pragliola, tarilabs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [tarilabs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment