Follow KF manifests guidelines

[lampajr]

As discussed in the last Kubeflow Manifest WG meeting (2024-04-18), this PR aims to properly setup manifests folder to follow the Kubeflow manifests guidelines

Description

Given that, with kubeflow/manifests#2682 we are going to add a custom script to sync Kubeflow Model Registry manifests from this repository to the Kubeflow Manifests one. In this PR I am adding missing files to follow the aforementioned Kubeflow manifests guidelines.

These are the requirements for all components under /contrib:

• There must be a README.md file that documents:
  • Instructions on how someone can install the component in a Kubeflow cluster
    • Since Kubeflow manifests have standardized on Kustomize
      we expect all manifests to be a kustomize packages
  • How to use the component as part of Kubeflow (examples)
  • The problems it tries to solve and the value it brings
  • Links to the official documentation of the component
• There must be an OWNERS file with at least 2 users
• There must be an UPGRADE.md file that documents any instructions users need
  to follow when applying manifests of a newer version
• There needs to be sufficient work on testing
  • There must be a script file [python, bash etc] that vefiries the component
    is working as expected. This can be something very simple, like submitting a
    CustomResource and waiting for it to become Ready
  • The maintainers will need to work with the leads of Manifests WG to ensure
    there's some basic automation in place that will be running the above script(s)
  • [edit] This is going to be addressed with Setup KF Model Registry GH tests manifests#2694

How Has This Been Tested?

Merge criteria:

• The commits and have meaningful messages; the author will squash them after approval or 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

[lampajr]

Hi @tarilabs @rimolive , this is a first draft aiming to fill most of the gaps in order to follow Kubeflow Manifests guideline.

In the PR description, I summarized what can be done as part of this PR but as initial step I created a simple README and OWNERS file (lmk which members you'd like to put there).

What I don't know yet are:

• If we want to include a simple test.sh script
• If we have an upgrade script (don't think so but let me know)

NOTE: I decided to create the PR directly in Model Registry repository as the script that will be added as part of kubeflow/manifests#2682 will copy the whole manifests/kustomize folder.. so easier to keep everything here such that we have a single source of truth.

NOTE2: I linked the documentation of model registry based on the currently open pull request kubeflow/website#3698, this means that those links will work only when the Kubeflow website will be updated with those changes

[tarilabs]

There needs to be sufficient work on testing

When I was looking into this I was thinking of:

model-registry/.github/workflows/build-image-pr.yml

Lines 44 to 63 in 2d3aa49

	- name: Create Test Registry
	env:
	IMG: "${{ env.IMG_ORG }}/${{ env.IMG_REPO }}:${{ steps.tags.outputs.tag }}"
	run: |
	echo "Download kustomize 5.2.1"
	mkdir $GITHUB_WORKSPACE/kustomize
	curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash -s "5.2.1" "$GITHUB_WORKSPACE/kustomize"
	PATH=$GITHUB_WORKSPACE/kustomize:$PATH
	echo "Display Kustomize version"
	kustomize version
	echo "Deploying Model Registry using Manifests; branch ${BRANCH}"
	kubectl create namespace kubeflow
	cd manifests/kustomize/overlays/db
	kustomize edit set image kubeflow/model-registry:latest $IMG
	kustomize build | kubectl apply -f -
	- name: Wait for Test Registry Deployment
	run: |
	kubectl wait --for=condition=available -n kubeflow deployment/model-registry-db --timeout=5m
	kubectl wait --for=condition=available -n kubeflow deployment/model-registry-deployment --timeout=5m
	kubectl logs -n kubeflow deployment/model-registry-deployment

which is done with every PR, mimics what there is in the readme which you contributed, and for me it's spot-on; what are your thoughts on this point @rimolive please?

[lampajr]

There must be an UPGRADE.md file that documents any instructions users need
to follow when applying manifests of a newer version

@tarilabs regarading this point, is there any upgrade process at the moment? I don't think so, as we do not have a release yet, but I'd like a confirmation on this point.

Anyway based on the other components, I think that for this we could simply rely on the official Kubeflow documentation (and put any instruction there, or even here in the README that I am adding with this PR).

[tarilabs]

thanks @lampajr again for this PR, to me:

• the OWNERS file is redundant (reasons below)
• wrt to testing, unless comments coming from Manifest WG/leads, I'd assume Follow KF manifests guidelines #69 (comment)
• wrt to update, at this moment we don't have any update procedure documented, further it's only Alpha so there is no b/c guarantee regardless atm

[lampajr]

thanks @lampajr again for this PR, to me:

• wrt to testing, unless comments coming from Manifest WG/leads, I'd assume Follow KF manifests guidelines #69 (comment)

yeah I agree, don't know if we want to extract those checks in a separate script such that it can be easily run as sanity check while deploying KF from manifests. In that case we could place that script here.

• wrt to update, at this moment we don't have any update procedure documented, further it's only Alpha so there is no b/c guarantee regardless atm

+1, I think we can skip this req, at least at the moment.

Anyway, happy to discuss and set how to proceed on this topic in the next KFMR meeting 🚀

[tarilabs]

as discussed in KF bi-weekly Model Registry meeting

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lampajr, 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