Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Explore Getting component Manifests directly from the component repos #338

Closed
4 tasks done
Tracked by #440
VaishnaviHire opened this issue Jul 18, 2023 · 2 comments
Closed
4 tasks done
Tracked by #440

Explore Getting component Manifests directly from the component repos #338

VaishnaviHire opened this issue Jul 18, 2023 · 2 comments
Assignees
@zdtsw
Labels
enhancement New feature or request rearchitecture Issues under re-architecure poc

Comments

@VaishnaviHire
Copy link
Member

VaishnaviHire commented Jul 18, 2023 •
edited by zdtsw
Loading

Is your feature request related to a problem? Please describe.
Currently the operator pulls manifests from odh-manifest repo. Since it is just a collection of component manifest, explore ways to update Operator build to include component manifests directly from respective repos

Further we can also update DSC CR to include remote manifest uri only for dev mode.
@VaishnaviHire VaishnaviHire added the enhancement New feature or request label Jul 18, 2023
@VaishnaviHire VaishnaviHire added the rearchitecture Issues under re-architecure poc label Jul 18, 2023
@zdtsw
Copy link
Member

zdtsw commented Jul 31, 2023 •
edited
Loading

one possibility is: (talked with Daniele)

component team own part of the odh-manifests
move manifets files to their git repo config/ folder

in operator, we have a mapping file (like the upstream_midstream.yaml)
with source component git repo url and point to config/ folder by default

during operator image build time, COPY/ADD these files from every git repo listed in mapping file.

@VaishnaviHire
Copy link
Member Author

VaishnaviHire commented Jul 31, 2023 •
edited
Loading

Yes this should work.

For remote manifests , we have 2 alternatives

  1. Expand DSCInitialization to every Component URI
  2. Since this is a dev setting, do not expose URIs in a CR, instead create a configmap that is watched by the operator

@VaishnaviHire VaishnaviHire mentioned this issue Aug 14, 2023
Closed
3 tasks
This was referenced Aug 28, 2023
Merged
Closed
Open
@danielezonca danielezonca mentioned this issue Aug 30, 2023
Closed
3 tasks
This was referenced Sep 28, 2023
Open
Closed
@zdtsw zdtsw mentioned this issue Oct 26, 2023
Closed
3 tasks
@zdtsw zdtsw closed this as completed Nov 25, 2023
ykaliuta pushed a commit to ykaliuta/opendatahub-operator that referenced this issue Sep 2, 2024
@zdtsw
upgrade: controller-runtime and code change accordingly (opendatahub-…
a5980f0 
…io#1189) (opendatahub-io#338)

* upgrade: controller-runtime and code change accordingly
- the current controller-runtime 0.14.6 does not support new featurs:
- uplift controller-runtime to v0.17.5 which is the last support go 1.21
- update Watches() to match 0.17.5
- cleanup old go.mod, remove unnecessary replacement
- some formatting for SetupWithManager()
- add missing "get" on console
---------

(cherry picked from commit 03c1abc)

Signed-off-by: Wen Zhou <wenzhou@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@zdtsw zdtsw

Labels
enhancement New feature or request rearchitecture Issues under re-architecure poc
Projects
Internal tracking
Status: Done
ODH Feature Tracking
Status: Platform
ODH Platform Planning
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

update: no more odh-manifests in ODH build zdtsw-forking/opendatahub-operator
2 participants
@zdtsw @VaishnaviHire