docs: add ADR for opendatahub.io API guidance

opendatahub-io / architecture-decision-records

Collection of Architectural Decision Records

Apache License 2.0

13 stars 33 forks source link

docs: add ADR for opendatahub.io API guidance #42

Closed zdtsw closed 2 months ago

zdtsw commented 5 months ago

ref: https://issues.redhat.com/browse/RHOAIENG-6524

Description

How Has This Been Tested?

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] 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

zdtsw commented 4 months ago

Works for me -- how do we track the work after this ADR?

this should be added in the checklist for any component before getting G.A in downstream.

zdtsw commented 4 months ago

@dhirajsb @rareddy add you two as reviewers too

zdtsw commented 3 months ago

@HumairAK / @anishasthana / @ruivieira / @RobGeada can I get this ARD reviewed?

tarilabs commented 3 months ago

@zdtsw fyi the PR title seems to have a typo: docs: add ADR for opendatahub.io API guid_e_nce

zdtsw commented 3 months ago

I'd recommend naming this "Kube API" rather than just "API".

In order to not confuse it with domain/REST API which a component may expose.

I do not follow this part: which one exactly you were referring to "Kube API" ?

tarilabs commented 3 months ago

I do not follow this part: which one exactly you were referring to "Kube API" ?

This document speaks about "API". But the content of this document, for as far as I can tell, deals with the CRD of components in ODH.

So I came to the document with the understanding I needed to adhere to a guideline for domain/REST API. In the case of Model Registry, i.e. this descriptor. This is because the document mentions "API", generically.

So I believe this ADR would best qualify if instead of speaking of "API" generically, substitutes s/API/Kube API/ to indicate we're speaking of the Kube API CRDs defined by each ODH compontent.

Wdyt?

dhirajsb commented 3 months ago

@zdtsw Model registry is not GA yet, so our CRD api version is still modelregistry.opendatahub.io/v1alpha1. That should be supported for new components, right?

zdtsw commented 3 months ago

@zdtsw Model registry is not GA yet, so our CRD api version is still modelregistry.opendatahub.io/v1alpha1. That should be supported for new components, right?

correct. you can stay v1alpha1 as long as Model registry not reach GA in downstream. this ADR will be used as a requirement for new components which plan to reach GA

zdtsw commented 3 months ago

I do not follow this part: which one exactly you were referring to "Kube API" ?

This document speaks about "API". But the content of this document, for as far as I can tell, deals with the CRD of components in ODH.

So I came to the document with the understanding I needed to adhere to a guideline for domain/REST API. In the case of Model Registry, i.e. this descriptor. This is because the document mentions "API", generically.

So I believe this ADR would best qualify if instead of speaking of "API" generically, substitutes s/API/Kube API/ to indicate we're speaking of the Kube API CRDs defined by each ODH compontent.

Wdyt?

Yes, I agree with your point. API can be a bit too board in this sense. I will update document to be more clear the scope here. thanks for the inputs!

github-actions[bot] commented 2 months ago

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 7 days.

github-actions[bot] commented 2 months ago

This PR was closed because it has been stale for 21+7 days with no activity.