[tracker]: transition for manifests for downstream components

[zdtsw]

list for the components to use component repo to host manifests in downstream:

• Downstream specific manifests - TBD e.g monitoring, osd-config
• dashboard @lucferbux: after discussion dashboard will keep using downstream odh-manifests for now.
• dsp
• workbench @harshad16
  • notebookimage
  • nbc
• kserve @Jooho
• modelmesh @Jooho
• DW @dimakis
  • codeflare
  • ray
• trusty @RobGeada / @ruivieira

[VaishnaviHire]

Should this be a rhods-1.35 tracker?

[HumairAK]

DSP is good to go on this front. Downstream component manifest location can be used for v2 operator deploys.

[VaishnaviHire]

DSP is good to go on this front. Downstream component manifest location can be used for v2 operator deploys.

Hi @HumairAK , for 1.34, we still would needDSP to update red-hat-data-services/odh-manifests. This is to ensure we have all the components migrated at once.

[HumairAK]

@VaishnaviHire yep, odh-manifests is already updated for v1.34, for dsp. We will probably update in v1.35 as well just to be safe.

[zdtsw]

want to have a check for the current progress of each component team:
do you feel we can make it for downstream 2.4 release on time or not?

@harshad16 @anishasthana @dimakis @Jooho @lucferbux @andrewballantyne

[anishasthana]

I'm feeling confident for distributed workloads.

[andrewballantyne]

We should be fine from a downstream manifests perspective. We'll make sure to sync again. FWIW, @VaishnaviHire & I did suggest a better RHODS integration model at the Architectural Council yesterday -- I made a follow up in slack as well.

[harshad16]

I think we can make it too, confidence level: moderate 😅
Working on it now, will keep you all updated.

[VaishnaviHire]

Hi @RobGeada , for trustyai we would need to update the component manifests to include rhods overlay

[israel-hdez]

Hey!

For downstream, KServe is ready. In KServe repo, the entrypoint you should use is config/overlays/odh (i.e., please, don't use config/default).

For ODH, we are still on it.

[harshad16]

Workbench updates:
We seem to be ready for the in-repo manifests pull.

1. Notebook images:
   Manifests path: manifests/base
   Branch: rhods-1.35

It should have all the imagestream set properly.

2. Notebook-controller:
   Manifests path: components/base
   Branch: rhods-1.35
   Note: This branch would be available, once DevOps creates them on feature-freeze.

[zdtsw]

Hey!

For downstream, KServe is ready. In KServe repo, the entrypoint you should use is config/overlays/odh (i.e., please, don't use config/default).

For ODH, we are still on it.

thanks! need to confirm the branch is "release-v0.11.0" to use ?

[zdtsw]

Workbench updates: We seem to be ready for the in-repo manifests pull.

1. Notebook images:
   Manifests path: manifests/base
   Branch: rhods-1.35

It should have all the imagestream set properly.

2. Notebook-controller:
   Manifests path: components/base
   Branch: rhods-1.35
   Note: This branch would be available, once DevOps creates them on feature-freeze.

thanks!
3 things to check:

• the new branch probably will be named as rhods-2.4 to cut over 1.35
• can we make the same structure for nbc just like in ODH? now in rhods the entrypoint is component/base with both 2 nbc, then we need to change the logic in the operator. Or if you can make two part, set the image in
  1. components/notebook-controller/config
  2. components/odh-notebook-controller/config
     then will be easier for us.
• is Manifests path: manifests/base is correct one to use? or should it be the notebooks/manifests/overlays/addintonal?

[harshad16]

@zdtsw thank you for the information.

thanks! 3 things to check:

• the new branch probably will be named as rhods-2.4 to cut over 1.35

On the Notebook repo, as per the direction:
we have cut the branch: https://github.com/red-hat-data-services/notebooks/tree/rhods-2.4

• can we make the same structure for nbc just like in ODH? now in rhods the entrypoint is component/base with both 2 nbc, then we need to change the logic in the operator. Or if you can make two part, set the image in

  1. components/notebook-controller/config
  2. components/odh-notebook-controller/config
     then will be easier for us.

Sorry i didn't follow this one.
Is this what you meant ? red-hat-data-services/kubeflow#29

• is Manifests path: manifests/base is correct one to use? or should it be the notebooks/manifests/overlays/addintonal?

To stay in line with what we had in RHODS/odh-manifest for notebook,
we have kept the in-repo manifests only as:
https://github.com/red-hat-data-services/notebooks/tree/rhods-2.4/manifests/base
if adding overlays/additional helps, let us know we can create that overlays.

[israel-hdez]

Hey!
For downstream, KServe is ready. In KServe repo, the entrypoint you should use is config/overlays/odh (i.e., please, don't use config/default).
For ODH, we are still on it.

thanks! need to confirm the branch is "release-v0.11.0" to use ?

@zdtsw Yes, that's the branch to use.
Although, I want to emphasize that this is for RHODS release. For ODH 1.11 release we expect to use a different branch.

EDIT: BTW, let me know if you will need a tag.

[zdtsw]

Hey!
For downstream, KServe is ready. In KServe repo, the entrypoint you should use is config/overlays/odh (i.e., please, don't use config/default).
For ODH, we are still on it.

thanks! need to confirm the branch is "release-v0.11.0" to use ?

@zdtsw Yes, that's the branch to use. Although, I want to emphasize that this is for RHODS release. For ODH 1.11 release we expect to use a different branch.

EDIT: BTW, let me know if you will need a tag.

sorry i am confused. so you want RHODS 2.4 build to use opendatahub-io/kserve release-v0.11.0 branch to get manifests?
i do not think we can cross org to do build.

• ODH can use opendatahub-io/kserve branch,
• RHODS need to use red-hat-data-services/kserve branch

[lucferbux]

@zdtsw We've created red-hat-data-services/odh-dashboard#302 for 2.4, it should include the same tree as the manifest had at that time, so except changing the location, i think the rest should be the same

[zdtsw]

@zdtsw We've created red-hat-data-services/odh-dashboard#302 for 2.4, it should include the same tree as the manifest had at that time, so except changing the location, i think the rest should be the same

thanks! i will do a test first

[Jooho]

@zdtsw Modelmesh is ready to use component manifests

• Manifest readiness for Operator v2 modelmesh-serving#237
• [Cherry-Pick] Manifests transition 0.11.0 modelmesh-serving#241 (RHODS 1.35)
• [Cherry-Pick] Manifests transition 0.11.1 modelmesh-serving#242 (ODH 1.11)

operator PR: #639

[zdtsw]

to wrap it up from offline discussion for kserve and modelmesh in RHODS:

• rhods-2.4 is the branch to build
• all 3 repo: kserve, odh-model-controller and model-mesh are ready

Question: still need to know where the old RHODS odh-manifests/modelmesh-monitoring should be mapped to
Answer: offline discuss, keep using odh-manifests for modelmesh-monitoring for rhods-2.4 and deprecate it in rhods-2.5

[zdtsw]

close this tracker as we have all components transit to in-repo manifests with dashboard as exception :P