Skip to content

Notes on Releasing Upstream, Midstream model‐registry

Jump to bottom
Matteo Mortari edited this page Dec 8, 2024 · 30 revisions

These are just some companion notes on the procedure currently used to release Upstream, Midstream model-registry.

Model Registry itself

At the time of writing, both repos are releasing from tags since there is no requirement for backporting. Eventually it should be switched to release from a branch (instead of tag).

Assuming:

odh	[email protected]:opendatahub-io/model-registry.git (fetch)
odh	[email protected]:opendatahub-io/model-registry.git (push)
origin	[email protected]:<your username>/model-registry.git (fetch)
origin	[email protected]:<your username>/model-registry.git (push)
upstream	[email protected]:kubeflow/model-registry.git (fetch)
upstream	[email protected]:kubeflow/model-registry.git (push)

and assuming local branch odh-main tracks on odh remote the main branch.

Prerequisites:

git checkout main
git pull upstream main

Example for 0.2.10, where Upstream no longer explicits the -alpha suffix (see here).

VVERSION=v0.2.10
TDATE=$(date "+%Y%m%d")
  • create the release branch upstream
git checkout -b release/$VVERSION
git push upstream release/$VVERSION

this creates the release branch upstream.

Create a PR to update what's needed on the release branch, i.e. the manifest images.

git checkout -b tarilabs-$TDATE-upstreamSync
pushd manifests/kustomize/base && kustomize edit set image kubeflow/model-registry=kubeflow/model-registry:$VVERSION && popd
pushd manifests/kustomize/options/csi && kustomize edit set image kubeflow/model-registry-storage-initializer=kubeflow/model-registry-storage-initializer:$VVERSION && popd
git add .
git commit -s

# suggested commit msg: "chore: align manifest for 0.2.10"

# using `git push origin`
# will give back convenient command on the screen for copy/paste:
git push --set-upstream origin tarilabs-20241108-upstreamSync

  • create PR ⚠️ targeting the release branch ⚠️ specifically (title ~like: chore: align manifest for 0.2.10)

  • merge the PR (you can manually add the approved, lgtm labels)

  • optional. if you create the tag from local git (see point below); await GHA complete that push Container images to docker.io or any other KF registry: https://github.com/kubeflow/model-registry/actions

  • create the Release from GitHub, ⚠️ select the release branch ⚠️ , input the new tag
    (in this example the tag is created from GitHub; alternatively, you could just do the tag manually by checking out the release branch locally--remember to pull!!--and issuing the tag from local machine). Encouraging in upstream to mark it as a non-production release (in the github screen). Encouraging to use the "alpha" version policy of KF in the beginning of the release markdown (see previous pre-releases).

It is helpful to prefix this in the release notes:

> **Alpha**
> This Kubeflow component has alpha status with limited support. See the [Kubeflow versioning policies](https://www.kubeflow.org/docs/started/support/#application-status). The Kubeflow team is interested in your [feedback](https://github.com/kubeflow/model-registry)about the usability of the feature.
  • before creating locally the release branch for midstream, you'll need to remove the previously created local branch
git branch -D release/$VVERSION
  • create the release branch midstream
git checkout odh-main
git pull odh main
git checkout -b release/$VVERSION
git push odh release/$VVERSION

this creates the release branch Midstream.

Create a PR to update what's needed on the release branch, i.e. the manifest images (although, these are not used in Midstream)

git checkout -b tarilabs-$TDATE-release-odh
pushd manifests/kustomize/base && kustomize edit set image quay.io/opendatahub/model-registry=quay.io/opendatahub/model-registry:$VVERSION && popd
pushd manifests/kustomize/options/csi && kustomize edit set image quay.io/opendatahub/model-registry-storage-initializer=quay.io/opendatahub/model-registry-storage-initializer:$VVERSION && popd
git add .
git commit -s

# suggested commit msg: "chore: align manifest for 0.2.10 for ODH"

# using `git push origin`
# will give back convenient command on the screen for copy/paste:
git push --set-upstream origin tarilabs-20241108-release-odh

Note

It is helpful to create the release branch in the operator at this point (see below)

pushd ../model-registry-operator
git checkout main
git pull upstream main
git checkout -b release/$VVERSION
git push upstream release/$VVERSION
popd

  • create PR ⚠️ targeting opendatahub-io organization and the release branch ⚠️ specifically (title ~like: chore: align manifest for 0.2.10 for ODH)

  • merge the PR

  • optional. if you create the tag from local git (see point below); await GHA complete that push Container images to docker.io or any other KF registry: https://github.com/opendatahub-io/model-registry/actions

  • create the Release from GitHub, ⚠️ select the release branch ⚠️ , input the new tag
    (in this example the tag is created from GitHub; alternatively, you could just do the tag manually by checking out the release branch locally--remember to pull!!--and issuing the tag from local machine)

  • release the MR Python client

git checkout release/$VVERSION
git pull odh release/$VVERSION
git tag py-$VVERSION
git push odh py-$VVERSION

At this point, Midstream is released, both the container image and the Python client on pypi.

Model Registry Operator

Assuming:

origin	[email protected]:<your username>/model-registry-operator.git (fetch)
origin	[email protected]:<your username>/model-registry-operator.git (push)
upstream	[email protected]:opendatahub-io/model-registry-operator.git (fetch)
upstream	[email protected]:opendatahub-io/model-registry-operator.git (push)
  • ensure the release branch was created as part of the release cycle above, or create it now if following a different process.

Note

this step is typically performed a bit earlier as part of the release of midstream.

git checkout main
git pull upstream main
git checkout -b release/v0.2.3
git push upstream release/v0.2.3

  • create PR ⚠️ targeting the release branch ⚠️ specifically you can follow this example: https://github.com/opendatahub-io/model-registry-operator/pull/116

  • merge the PR

  • create the Release from GitHub, ⚠️ select the release branch ⚠️ , input the new tag (in this example the tag is created from GitHub; alternatively, you could just do the tag manually by checking out the release branch locally--remember to pull!!--and issuing the tag from local machine)

Wiring to opendatahub-community

You can use this as example: https://github.com/opendatahub-io/opendatahub-community/issues/154#issuecomment-2226812326

Clone this wiki locally