Skip to content

Add local bundle for odh manifests - #202

Merged
openshift-merge-robot merged 10 commits into
opendatahub-io:masterfrom
maroroman:manifests-bundling
Jun 29, 2023
Merged

openshift-merge-robot merged 10 commits into
opendatahub-io:masterfrom
maroroman:manifests-bundling

Conversation

@maroroman

@maroroman maroroman commented Mar 2, 2023 •

Copy link
Copy Markdown
Contributor

Resolves: #196

Description

This PR adds a function that adds a check whenever KFApply is called to check if there are any Repos specified, if not, it takes local manifests that are downloaded at build time.

How Has This Been Tested?

  1. Deployed operator specified in the PR on a cluster

  2. Added the following KFDef:

    apiVersion: kfdef.apps.kubeflow.org/v1
          kind: KfDef
          metadata:
            name: odh-core-testing
          spec:
            applications:
            - kustomizeConfig:
                repoRef:
                  name: manifests
                  path: odh-common
              name: odh-common
            - kustomizeConfig:
                repoRef:
                  name: manifests
                  path: odh-dashboard
              name: odh-dashboard
    
    
  3. Verified that the operator took its local file and deployed the resources despite not having a repo specified.

  4. Verify that if the Repos section is specified, no functionality is broken.

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

@openshift-ci

openshift-ci Bot commented Mar 2, 2023

Copy link
Copy Markdown

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@maroroman

Copy link
Copy Markdown
Contributor Author

fmt automatically changed a bunch of go files according to conventions, I though I'd keep it in but I can take it out of hte PR if needed.

@maroroman
maroroman force-pushed the manifests-bundling branch from 9e845f6 to c8d542f Compare March 3, 2023 11:51
@maroroman
maroroman marked this pull request as ready for review March 3, 2023 11:58
@maroroman maroroman changed the title [WIP] Add local bundle for odh manifests Add local bundle for odh manifests Mar 3, 2023
@maroroman

Copy link
Copy Markdown
Contributor Author

/cc @LaVLaS

@openshift-ci
openshift-ci Bot requested a review from LaVLaS March 3, 2023 14:44
Comment thread Makefile Outdated
Comment thread controllers/kfdef.apps.kubeflow.org/kfdef_controller.go Outdated
Comment thread .gitignore Outdated
@LaVLaS

LaVLaS commented Mar 14, 2023

Copy link
Copy Markdown
Contributor

@maroroman It seems like many of the modified files have the empty whitespace and code comment changes. Can you revert the changes to those files so that the only commits are code changes?

@VaishnaviHire VaishnaviHire left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maroroman Awesome work!

Apart from the changes requested, can you also modify e2e tests to include the local KfDef ?

@maroroman
maroroman force-pushed the manifests-bundling branch 6 times, most recently from 7fefd44 to 22b9e62 Compare March 16, 2023 09:43
@maroroman

Copy link
Copy Markdown
Contributor Author

@LaVLaS @VaishnaviHire Reverted the whitespace and formatting changes unrelated to code change and added the local manfests to the e2e tests.

@maroroman
maroroman force-pushed the manifests-bundling branch from 22b9e62 to 00119e0 Compare March 17, 2023 10:12
@maroroman

Copy link
Copy Markdown
Contributor Author

Removed the DeepCopy() and added a check for the tarball

@maroroman
maroroman changed the base branch from feature/update-sdk to master March 31, 2023 11:35
@maroroman
maroroman force-pushed the manifests-bundling branch from 00119e0 to 50aa24f Compare March 31, 2023 12:02
Comment thread Dockerfile
@LaVLaS

LaVLaS commented Jun 29, 2023

Copy link
Copy Markdown
Contributor

/label tide/merge-method-squash

@openshift-ci

openshift-ci Bot commented Jun 29, 2023

Copy link
Copy Markdown

@LaVLaS: The label(s) tide/merge-method-squash cannot be applied, because the repository doesn't have them.

Details

In response to this:

/label tide/merge-method-squash

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@LaVLaS

LaVLaS commented Jun 29, 2023

Copy link
Copy Markdown
Contributor

/retest

@maroroman
maroroman force-pushed the manifests-bundling branch from e45901f to c6d190b Compare June 29, 2023 14:50
@LaVLaS

LaVLaS commented Jun 29, 2023

Copy link
Copy Markdown
Contributor

/retest

Last failure appears to be infrastructure issues

@openshift-ci

openshift-ci Bot commented Jun 29, 2023

Copy link
Copy Markdown

@maroroman: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/operator-e2e 50aa24f link true /test operator-e2e
ci/prow/unit-tests 50aa24f link true /test unit-tests
ci/prow/opendatahub-manifests-e2e cdd796d link false /test opendatahub-manifests-e2e

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@LaVLaS

LaVLaS commented Jun 29, 2023

Copy link
Copy Markdown
Contributor

/approve /lgtm

The container image is good the test failures appear to be related to the setup for the pipelines operator

@openshift-ci

openshift-ci Bot commented Jun 29, 2023

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: LaVLaS

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@LaVLaS

LaVLaS commented Jun 29, 2023

Copy link
Copy Markdown
Contributor

/lgtm

@openshift-ci openshift-ci Bot added the lgtm label Jun 29, 2023
@openshift-merge-robot
openshift-merge-robot merged commit ae55305 into opendatahub-io:master Jun 29, 2023
@bartoszmajsak bartoszmajsak mentioned this pull request Aug 31, 2023
ykaliuta pushed a commit to ykaliuta/opendatahub-operator that referenced this pull request Mar 8, 2024
* Update Owners and Owwners-aliases (opendatahub-io#869)

(cherry picked from commit 7f477a3)

* fix(DSC): do not reconcile resource if it has a special annotation (opendatahub-io#879)

* fix(DSC+Kserve): do not reconcile inferenceservice-config for
rawdeployment

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* fix: wrong logic

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* feat(deploy): do not set ownerreference if resource has sepcial
annotation to false

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* update: change logic to --if kind is CRD do not care annotation

* update: change logic

- we still set ownerreference on resources
- we only skip reconcile if resource has defined annotation

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* fix(typo)

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* Update: limite scope of annoation to only kserve resource for now

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

---------

Signed-off-by: Wen Zhou <wenzhou@redhat.com>
(cherry picked from commit 20f4ad0)

* fix(feature): use correct error variable name (opendatahub-io#882)

(cherry picked from commit 0d8bd14)

* allow setting default deployment mode for Kserve in DSC (opendatahub-io#864)

* allow setting default deployment mode for Kserve in DSC

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* move kserve config logic to separate file + enhancements

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* revert dev image set in operator CSV

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* only setup kserve config if component is enabled

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* bug fix

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* address PR feedback

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* cleanup

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* fix lint error

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* set default value for Kserve defaultDeploymentMode to be empty

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* more pr feedback

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* update bundle

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* enhance documentation

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* add readme for dev preview

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

---------

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>
(cherry picked from commit cebd287)

* Update bundle

---------

Co-authored-by: Wen Zhou <wenzhou@redhat.com>
Co-authored-by: Ivan Necas <necasik@gmail.com>
Co-authored-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>
robotmaxtron pushed a commit to robotmaxtron/opendatahub-operator that referenced this pull request Sep 17, 2025
* Update Owners and Owwners-aliases (opendatahub-io#869)

(cherry picked from commit 7f477a3)

* fix(DSC): do not reconcile resource if it has a special annotation (opendatahub-io#879)

* fix(DSC+Kserve): do not reconcile inferenceservice-config for
rawdeployment

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* fix: wrong logic

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* feat(deploy): do not set ownerreference if resource has sepcial
annotation to false

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* update: change logic to --if kind is CRD do not care annotation

* update: change logic

- we still set ownerreference on resources
- we only skip reconcile if resource has defined annotation

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* fix(typo)

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

* Update: limite scope of annoation to only kserve resource for now

Signed-off-by: Wen Zhou <wenzhou@redhat.com>

---------

Signed-off-by: Wen Zhou <wenzhou@redhat.com>
(cherry picked from commit 20f4ad0)

* fix(feature): use correct error variable name (opendatahub-io#882)

(cherry picked from commit 0d8bd14)

* allow setting default deployment mode for Kserve in DSC (opendatahub-io#864)

* allow setting default deployment mode for Kserve in DSC

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* move kserve config logic to separate file + enhancements

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* revert dev image set in operator CSV

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* only setup kserve config if component is enabled

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* bug fix

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* address PR feedback

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* cleanup

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* fix lint error

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* set default value for Kserve defaultDeploymentMode to be empty

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* more pr feedback

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* update bundle

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* enhance documentation

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

* add readme for dev preview

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>

---------

Signed-off-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>
(cherry picked from commit cebd287)

* Update bundle

---------

Co-authored-by: Wen Zhou <wenzhou@redhat.com>
Co-authored-by: Ivan Necas <necasik@gmail.com>
Co-authored-by: Vedant Mahabaleshwarkar <vmahabal@redhat.com>
Signed-off-by: Max Whittingham <mwhittingham@redhat.com>
kpunwatk added a commit to kpunwatk/opendatahub-operator that referenced this pull request Sep 16, 2026
…fixes

Sync opendatahub-io/trustyai-service-operator main to opendatahub-io#202 merge (9c0ffa8).

Co-authored-by: Cursor <cursoragent@cursor.com>
kpunwatk added a commit to kpunwatk/opendatahub-operator that referenced this pull request Sep 16, 2026
…fixes

Sync opendatahub-io/trustyai-service-operator main to opendatahub-io#202 merge (9c0ffa8).
openshift-merge-bot Bot pushed a commit that referenced this pull request Sep 22, 2026
* feat: migrate TrustyAI from component to module

Rewrites the TrustyAI module handler against the current ModuleHandler
interface (PopulatePlatformModule/IsEnabled/BuildModuleCR signatures and
ModuleConfig fields changed significantly since the previous attempt in
PR #3643, which predates the DAG-orchestration and common
action-framework refactors). Follows sparkoperator's handler as the
template, since both are out-of-tree kustomize-based modules with their
own dedicated operator image.

- Add internal/controller/modules/trustyai/handler.go + handler_test.go
- Add PlatformModules.TrustyAI field (DSC mode only for now; Platform/xKS
  mode deferred pending API updates, matching the original migration's
  scope decision)
- Register TrustyAI in existingModules/moduleRunlevels (RL(32), after
  KServe's RL(31), since TrustyAI depends on KServe CRDs)
- Remove TrustyAI from existingComponents/componentRunlevels and delete
  the legacy in-tree component controller and its monitoring resources
- CRName uses componentApi.TrustyAIInstanceName ("default-trustyai"),
  now aligned with the trustyai-operator-module CRD's own singleton
  validation (see companion fix in trustyai-service-operator)

* fix(trustyai): use current image var name, add RHOAI build-config exception

RELATED_IMAGE_ODH_TRUSTYAI_SERVICE_IMAGE was renamed to
RELATED_IMAGE_ODH_TRUSTYAI_SERVICE_PY_IMAGE (#4011) before this
migration branch was rebased; the RelatedImages list still had the
stale name. Also adds an RHOAI-Build-Config exception for the new
RELATED_IMAGE_ODH_TRUSTYAI_MODULE_OPERATOR_IMAGE, matching the
trainer/sparkoperator module operator images (RHOAIENG-80231,
delivering in RHOAI 3.6 EA2). Confirmed via `make validate-related-images`
locally: 2 errors -> 0.

* docs: regenerate api-overview for TrustyAI module field

make generate manifests-all api-docs picked up the new
PlatformModules.TrustyAI field added in the previous commit.

* fix(trustyai): register manifests-config entry, fix ManifestDir/ContextDir mismatch

Two bugs causing "must build at directory: not a valid directory:
evalsymlink failure on '/opt/manifests/trustyai-module-operator/default'"
at deploy time:

- manifests-config.yaml had no entry for the module at all, so
  `make get-manifests` never fetched it. Added trustyai-module-operator,
  reusing the exact same repo/ref pins as the existing trustyai
  (component) entry, since both mirrors already have
  trustyai-operator-module/ at those SHAs -- confirmed via the GitHub
  API before adding.

- handler.go's ManifestDir was missing ContextDir: "default". Every
  other kustomize-based module (e.g. trainer) points sourcePath at the
  whole `config` directory and lets ContextDir select the `default`
  overlay at render time; PlatformModules.String() joins Path+ContextDir,
  so without it the platform looked for manifests directly under
  ManifestDir instead of ManifestDir/default -- the exact directory
  missing in the reported error.

Verified end to end: `make get-manifests` now fetches
trustyai-operator-module/config/{crd,rbac,manager,default} correctly,
and `kustomize build opt/manifests/trustyai-module-operator/default`
renders successfully.

* fix(trustyai): align RBAC markers and e2e tests with module architecture

RBAC markers for the trustyais CR belonged in internal/controller/modules
(module-managed), not datasciencecluster; moved them accordingly with no
change to generated output. Updated dag_ordering_test.go and
resilience_test.go to treat TrustyAI as a module like the other
already-migrated components (Trainer, Workbenches, Dashboard, AIHub),
matching gaps found by comparing against PR #4000.

* fix(trustyai): reuse existing trustyai manifests-config entry instead of a duplicate

The old trustyai entry (sourcePath: config) pointed at the removed in-tree
component manifests and had no remaining code consumer, so keeping a
separate trustyai-module-operator entry alongside it was redundant.
Repointed the existing entry's sourcePath at the module manifests and
dropped the duplicate.

* fix(trustyai): explicitly map permit fields instead of blind struct conversion

BuildModuleCR converted the whole DSC-facing TrustyAICommonSpec into the
module CR's spec via runtime.DefaultUnstructuredConverter. The DSC-facing
API declares permitCodeExecution/permitOnline as a string enum
("allow"/"deny") while the module CRD declares them as bool, so the
wholesale conversion projected a string into a field the module's typed
client expects to be bool, breaking its watch/list reflector on
existing CRs. Map the two permit fields explicitly with the
string-to-bool conversion instead.

Reported-by: Steven Tobin

* fix(trustyai): bump rhoai manifest pin to pick up CR-naming fix

The rhoai-3.6-ea.2 pin predated commit 5ed6709 (fix(module): align
TrustyAI singleton CR name with sibling modules), so the deployed
module CRD still required metadata.name == 'default' while
BuildModuleCR creates 'default-trustyai', causing every apply to be
rejected by the CRD's own CEL validation. Bumped to the branch's
current tip, which already includes the fix (verified via
GitHub compare API and by re-downloading manifests locally).

The odh pin (opendatahub-io/trustyai-service-operator@incubation)
still needs the same fix; that branch hasn't been re-synced from
main since before the fix landed, so it's left unchanged pending
that sync.

Reported-by: Steven Tobin

* fix(trustyai): switch odh manifest pin from incubation to main

The incubation branch (opendatahub-io/trustyai-service-operator) is
synced from that repo's own main via a separate, infrequent process
(last sync 2026-08-05), and hasn't picked up the CR-naming CEL fix
(commit 5ed6709, landed 2026-09-01) that the rhoai pin already has.
Waiting on that sync is unbounded, and this file already has
precedent for pinning odh directly at main (see the modelregistry
entry), so switch to main@<sha> instead. Verified the pinned commit
contains the fix by fetching the CRD directly and confirming the
CEL rule reads 'default-trustyai', and by re-running
`make get-manifests` + `kustomize build` locally.

Reported-by: Steven Tobin

* fix(trustyai): bump odh/rhoai manifest pins to pick up module operator fixes

trustyai-service-operator#908 (RBAC watch verbs, /opt write permission,
platform version handshake) has now propagated through both downstream
sync chains:

- odh: opendatahub-io/trustyai-service-operator#194 merged
- rhoai: red-hat-data-services/trustyai-service-operator#1932 (into
  main) and #1934 (main into rhoai-3.6-ea.2) both merged

Bumped both pins to the post-merge tips and verified locally: the
"watch" verb is present on deployments/rolebindings in both ODH and
RHOAI mode, kustomize build succeeds, and go build/test pass.

Reported-by: Steven Tobin

* fix(trustyai): remove redundant CRD-generating types now owned by the module

TrustyAI's Go type still had +kubebuilder:object:root=true on TrustyAI/
TrustyAIList, plus the PlatformObject interface implementation and
scheme registration. Since the CRD is now installed by
trustyai-operator-module (from its own manifests), this caused
opendatahub-operator to generate a second, competing CRD definition
for the same GVK from a Go type that isn't kept in sync with the
module's actual schema (already missing mcpGuardrailsMode and the
default-trustyai singleton validation independently added on each
side).

Removed the top-level TrustyAI/TrustyAIList struct, scheme
registration, and PlatformObject methods, keeping only the nested
spec/status types and DSCTrustyAI/DSCTrustyAIStatus, matching the
pattern already used by sibling modules (see sparkoperator_types.go).

Updated tests/e2e/trustyai_test.go to use NewModuleTestCtx (GVK +
instance name) instead of NewComponentTestCtx (which required a typed
struct) -- this is the existing mechanism other module e2e tests
(kserve_test.go, aigateway_test.go) already use for exactly this case.

Verified via a full config/crd/bases wipe + make manifests that no
components.platform.opendatahub.io_trustyais.yaml is generated anymore.

* fix(trustyai): bump rhoai manifest pin to pick up #913 (services/prometheuses watch)

trustyai-explainability/trustyai-service-operator#913 merged and has
propagated through both red-hat-data-services sync hops (main, then
rhoai-3.6-ea.2). Bumped the rhoai ref and verified locally: services
and prometheuses RBAC rules now include watch.

The odh pin is not bumped yet -- opendatahub-io/trustyai-service-operator#195
(the pull[bot] sync PR) already has the right content but hasn't merged.

* fix(trustyai): temporarily point odh pin at canonical upstream repo

opendatahub-io/trustyai-service-operator#195 (the pull[bot] sync PR
bringing in #913's services/prometheuses watch fix) already has the
right content as its head commit, but is stuck on the OWNERS approval
gate while the approver is on PTO. Rather than wait, point the odh
pin directly at trustyai-explainability/trustyai-service-operator
(the canonical upstream #195 pulls from) at that same commit.

Verified locally: make get-manifests resolves cleanly, RBAC role.yaml
has watch on services/prometheuses, CRD CEL rule reads
'default-trustyai', kustomize build succeeds, go build/test pass.

Switch back to the opendatahub-io mirror once #195 merges.

* switch ODH manifest pin back to opendatahub-io mirror

* bump(trustyai): rhoai manifest pin to pick up rhoai PR #1943

Picks up the same fixes that were merged into the ODH upstream repo.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

* bump(trustyai): manifest pins for #920/#921/#925 sync

Pick up post-sync mirror SHAs: ODH main @0b428d2 (#197) and
rhoai-3.6-ea.2 @5f278d7 (#1949), including the emptyDir/clearDir fix.

Co-authored-by: Cursor <cursoragent@cursor.com>

* bump(trustyai): update module operator image digest to latest build

* sync manager image overrides and regenerate api docs

* chore: resolve image digests after trustyai manifest sync

* bump(trustyai): service operator image only; revert broad digest resolve
Update RELATED_IMAGE_ODH_TRUSTYAI_SERVICE_OPERATOR_IMAGE to fix
--metrics-cert-path crash. Reverts platform-wide resolve-image-digests
from 4e0700d; module operator stays at e5cd204a (#925).

* fix(trustyai): TrustyAI-only image pins at latest validated digests

* fix(trustyai): drop unrelated data-registry rhoai digest from PR

Keep manifests-config image pin changes TrustyAI-only; remove
MOD_ARCH_DATA_REGISTRY rhoai block not in scope for #4051.

Co-authored-by: Cursor <cursoragent@cursor.com>

* Revert "fix(trustyai): drop unrelated data-registry rhoai digest from PR"
Restore MOD_ARCH_DATA_REGISTRY rhoai mapping from upstream #4073 merge.

* test(e2e): drop TrustyAI from platform-owned CRD validation

TrustyAI is now an out-of-tree module; its CRD is installed by the
module operator when enabled, not by the platform operator at startup.

Co-authored-by: Cursor <cursoragent@cursor.com>

* chore(manifests): bump trustyai rhoai ref after #1955 sync

Pick up #926 module operator fixes on rhoai-3.6-ea.2 (RELATED_IMAGE mapping,
manifest staging, memory limits).

* chore(manifests): bump trustyai odh ref to pick up #926 fixes

Sync opendatahub-io/trustyai-service-operator main to #202 merge (9c0ffa8).

* chore(manifests): bump trustyai pins for #928 readiness fix

- ODH main@feb5b94 (opendatahub-io #204)
- RHOAI rhoai-3.6-ea.2@75a4af5 (#1956 / #928 on rhoai)
- Module-operator image digest d2df18f5 (Konflux build for feb5b94)

* chore(manifests): align TrustyAI module-operator image with build configs

- ODH: quay.io/opendatahub/odh-trustyai-module-operator@b3cef1149
- RHOAI: quay.io/rhoai/odh-trustyai-module-operator-rhel9@51384d9610
- Remove stale rhoai_exceptions entry (RHOAIENG-80231 onboarded)

Co-authored-by: Cursor <cursoragent@cursor.com>

* feat(trustyai): propagate MCP Guardrails mode

Signed-off-by: Rui Vieira <ruidevieira@googlemail.com>
(cherry picked from commit 8a76d74)

* chore(docs): regenerate api-overview after Ray/TrustyAI module migration

Drop Ray and TrustyAI from the platform-owned Resource Types index so
make api-docs matches CI (Ensure generated files are included).

Co-authored-by: Cursor <cursoragent@cursor.com>

* fix(trustyai): bump module refs to include mcpGuardrailsMode in CRD schema

ODH: main@7838ba58fffca619610c6b260c4ec87c031d0a27 (was feb5b944...)
RHOAI: rhoai-3.6-ea.2@9a3b7b9f4f936419451c833b70ba180fe03a3e61 (was 75a4af5b...)

The previous refs lacked mcpGuardrailsMode in the TrustyAI CRD schema,
causing deployment failures when trying to apply the field: "field not
declared in schema". Newer upstream commits include this field.

Fixes e2e test failure: "unable to patch components.platform.opendatahub.io/v1alpha1,
Kind=TrustyAI default-trustyai: failed to create typed patch object: .spec.mcpGuardrailsMode:
field not declared in schema"

* fix(trustyai): bump module operator image digests to latest builds

Update both ODH and RHOAI image digests to the latest trustyai-module-operator
builds that include the MCP guardrails fix:

- ODH: sha256:65cba5211000f9b13b87b2bd9f1fb052ea814e1826e53f498edd84209d877b6e
  (midstream incubation→stable sync by Rui, synced to ODH)
- RHOAI: sha256:e6a0be61ecbedf259b80fc2a63ae8ee975aa18a6a6743538554b21bab9f7bd4c

Previous digests were stale and not available in the registry, causing
e2e test deployment failures with missing CRD fields.

* test(trustyai): override ValidateOperandsOwnerReferences for modular architecture

TrustyAI is now a module operator that deploys operands with different labels.
Override the parent test implementation to use the correct TrustyAI-specific label
'app.kubernetes.io/part-of: trustyai' instead of the generic component label,
and verify operands are owned by the TrustyAI CR by kind and name.

* style(test): fix import order in trustyai_test.go

* align the trusty tests to the module architecture

* Align RHOAI TrustyAI Module operator with RHOAI manifests

* Fix Missing Components CRD Handling test

---------

Signed-off-by: Rui Vieira <ruidevieira@googlemail.com>
Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Rui Vieira <ruidevieira@googlemail.com>
Co-authored-by: Steven Tobin <stobin@redhat.com>
Co-authored-by: Marián Macik <mmacik@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[feature/update-sdk] Add support for bundling the odh-manifest into the operator image

4 participants