Added types for notebook image and REST end point stubs.

[dlabaj]

Updated with REST api BYON notebook image endpoints and new notebook image types.

Here is a link to the BYON REST api:

https://studio-ws.apicur.io/sharing/f34aaaa8-58e0-48fb-b36f-1d91ac5ebf48

Relates to issue #140 and open-services-group/byon#18

[tumido]

@dlabaj can we revisit this? Is this schema based on https://studio.apicur.io/preview?aid=66775#operation/getNotebooks ?

I think this doesn't match, because:

1. We have no idea about a repo. We import from container image repository not github repository. Can we call this url?
2. Can we change status to phase so it matches the backend names better?

[dlabaj]

For item 1 we can definitely change it to "URL" Should we update mocks ups so they say URL as well? https://marvelapp.com/prototype/6dcfc3h/screen/85139860

For item 2 it should have been phase. Status from this mockup I am assuming would show the phase while it's being imported and then change to the visible value (aka enabled / disabled) setting once it reaches success? https://marvelapp.com/prototype/6dcfc3h/screen/85139859
@tumido Let me know if that's your understanding as well.

[tumido]

For item 1

I think this is a tricky part on the UI. Imagine this example. You go to URL https://quay.io/repository/tcoufal/jh-minimal-test. This image can be pulled by podman/docker as quay.io/tcoufal/jh-minimal-test URI which in container terminology (see https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction#repository) is referred to as a "repository"...

If we name it URL in the UI, we need to clarify to the user we want the quay.io/tcoufal/jh-minimal-test value, not https://quay.io/repository/tcoufal/jh-minimal-test. On the other hand, naming it "Repository" carries the "code repository" connotation (as seen in the API example)...

In addition to that, we have an annotation in JupyterHub ImageStreams called opendatahub.io/notebook-image-url. This annotation is used to point to the git repo where the source code for the image lives. Again, using the url and repository as synonyms...

In the BYON pipelines, we call the parameter URL.

Honestly the more I think about it, the more confused I am... I think I'm overcomplicating things but I would really like to have things named consistently. No matter which term we end up using.

For item 2

Honestly, I think this is a common confusion and inconsistency in OpenShift. Take Pods as an example:

The UI shows column named Status but API serves the value in .status.phase field...

In our case we're gonna source this value from opendatahub.io/notebook-image-phase annotation. So... I think for the sake of UI consistency the column should be definitely called "Status" (user expect that based on the rest of OpenShift UI). When it comes to the API side, the custom is to call this value a phase, since status usually means a complex field containing many different status-related information.

[tumido]

I also think we're missing here the field for messages -> this is populated in case the import finds some violations and refuses to import. It's a suggestion to user about what went wrong. See:

https://marvelapp.com/prototype/6dcfc3h/screen/85139862

In the OpenShift resource it is defined as a JSON encoded string (we can parse it in the backend):

[{"severity":"error","message":"Python version does not meet minimal required version ('3.8.0')"}]

[dlabaj]

@tumido
Wouldn't this come back as an error message in say 400 response. e.g. https://github.com/dlabaj/odh-dashboard/blob/660f6a3b24caa63c5578d33dcb4975a54f066146/backend/src/routes/api/notebook/notebooksUtils.ts#L66 or not?

[tumido]

I don't think so.. I think you want to get a 200 message and still receive the messages/recommendations.

The import action is an async process. So the API doesn't know this data at the time or a POST to /api/notebooks.

When you do GET on /api/notebooks you should receive all the images and some of them will have status "Succeeded" and some of them may have status "Failed" with the messages populated...

Presence of the messages doesn't mean the resource doesn't exist (or that you should not be requesting it - as 400 would imply), it means the import has failed due to any reason and you should receive a valid 200 with a payload + those details. Imagine this being a failing/crashing pod resource. If you do a get request for it, you still get the object json/yaml no matter the failing state...

[dlabaj]

okay will add this field.