Repository navigation
feat (intelligent-assistant): add optional OKP flavour for Intelligent Assistant [RHIDP-16103] - #3370
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3370 +/- ##
==========================================
+ Coverage 59.84% 60.07% +0.23%
==========================================
Files 51 51
Lines 3586 3612 +26
==========================================
+ Hits 2146 2170 +24
- Misses 1246 1247 +1
- Partials 194 195 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
51db81c to
3bbec01
Compare
|
Corresponding rhdh-chart PR redhat-developer/rhdh-chart#500 |
Move the OKP (Offline Knowledge Portal) Deployment, Service, and Route out of imperative Go construction in internal/controller/okp.go and into the lightspeed flavour as YAML manifests, so OKP is described like every other flavour resource and its image string rides in the bundle ConfigMap (visible to midstream image pinning). Addresses PR redhat-developer#3370 review comment: "should OKP be in the flavour YAML rather than Go?". Each OKP object is a separately registered model key (OkpDeploymentKey, OkpServiceKey, OkpRouteKey) with its own MergeFunc, and stays gated to OpenShift in addToModel. Flavour gating is implicit (files live only in flavours/lightspeed/). The runtime behavior is unchanged: same objects, same OpenShift-only gating, same OKP_SERVICE_URL injection into the lightspeed-core sidecar before apply (no dual ReplicaSet). Remove applyOkpResources; OKP now flows through the normal applyObjects(GetRuntimeObjects()) SSA path. Keep prepareOkpEnvVar and prepareOkpConfig as controller wiring. Regenerate bundle manifests and dist/rhdh/install.yaml. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Move the OKP (Offline Knowledge Portal) Deployment, Service, and Route out of imperative Go construction in internal/controller/okp.go and into the lightspeed flavour as YAML manifests, so OKP is described like every other flavour resource and its image string rides in the bundle ConfigMap (visible to midstream image pinning). Addresses PR redhat-developer#3370 review comment: "should OKP be in the flavour YAML rather than Go?". Each OKP object is a separately registered model key (OkpDeploymentKey, OkpServiceKey, OkpRouteKey) with its own MergeFunc, and stays gated to OpenShift in addToModel. Flavour gating is implicit (files live only in flavours/lightspeed/). The runtime behavior is unchanged: same objects, same OpenShift-only gating, same OKP_SERVICE_URL injection into the lightspeed-core sidecar before apply (no dual ReplicaSet). Remove applyOkpResources; OKP now flows through the normal applyObjects(GetRuntimeObjects()) SSA path. Keep prepareOkpEnvVar and prepareOkpConfig as controller wiring. Regenerate bundle manifests and dist/rhdh/install.yaml. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
15302a5 to
ecd3199
Compare
|
/build-images |
|
❌ Image build failed See workflow run for details: https://github.com/redhat-developer/rhdh-operator/actions/runs/32705736214 Triggered by @rm3l |
|
/build-images |
|
❌ Image build failed See workflow run for details: https://github.com/redhat-developer/rhdh-operator/actions/runs/32705962118 Triggered by @rm3l |
Move the OKP (Offline Knowledge Portal) Deployment, Service, and Route out of imperative Go construction in internal/controller/okp.go and into the lightspeed flavour as YAML manifests, so OKP is described like every other flavour resource and its image string rides in the bundle ConfigMap (visible to midstream image pinning). Addresses PR redhat-developer#3370 review comment: "should OKP be in the flavour YAML rather than Go?". Each OKP object is a separately registered model key (OkpDeploymentKey, OkpServiceKey, OkpRouteKey) with its own MergeFunc, and stays gated to OpenShift in addToModel. Flavour gating is implicit (files live only in flavours/lightspeed/). The runtime behavior is unchanged: same objects, same OpenShift-only gating, same OKP_SERVICE_URL injection into the lightspeed-core sidecar before apply (no dual ReplicaSet). Remove applyOkpResources; OKP now flows through the normal applyObjects(GetRuntimeObjects()) SSA path. Keep prepareOkpEnvVar and prepareOkpConfig as controller wiring. Regenerate bundle manifests and dist/rhdh/install.yaml. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
71c206f to
9726670
Compare
|
/build-images |
|
✅ PR images built successfully! Images are available for testing:
Also available with PR number tag:
Triggered by @maysunfaisal |
Jdubrick
left a comment
Jdubrick
left a comment
There was a problem hiding this comment.
Just a general question as well: will OKP get cleaned up if someone disables the lightspeed flavour?
|
/cc @gazarenkov |
|
/build-images |
|
✅ PR images built successfully! Images are available for testing:
Also available with PR number tag:
Triggered by @maysunfaisal |
gazarenkov
left a comment
gazarenkov
left a comment
There was a problem hiding this comment.
To add the additional resources needed for your plugin please use Plugin dependencies feature instead.
You can see how it implemented in orchestrator flavour as well (it uses sonataflow dependencies).
|
✅ PR images built and pushed successfully! Images are available for testing (expires in 7 days):
|
|
@rm3l @gazarenkov the PR has been rebased, pls take a look. thank you! |
|
/agentic_review |
Code Review by Qodo
1. Portal pods fail on standard Kubernetes
|
![rhdh-qodo-merge[bot]](https://avatars.githubusercontent.com/in/1961108?s=60&v=4){kind=small}
|
@maysunfaisal PTAL at the QODO comments above, thanks! |
There was a problem hiding this comment.
OpenShift E2E (reviewer testing)
Environment: api-ci-ln-ml0w6fb-76ef8.origin-ci-int-aws.dev.rhcloud.com, operator quay.io/rhdh-community/operator:2.1.0-pr-3370-fff2b29 via make deploy. Five Backstage instances in okp-e2e-* namespaces (default IA, IA-only, IA+OKP doc order, OKP-only, reversed flavour order).
Worked: Doc-order IA+OKP and OKP-only — OKP Route HTTP 200, correct lightspeed-core args with lightspeed-stack-okp.yaml when IA is listed before OKP (or OKP-only). Default / IA-only had no OKP workloads.
Issues (details in inline comments): Reversed flavour order; OKP resources not removed when flavour disabled; temporary lightspeed-core CrashLoop until OKP image/Solr ready.
|
✅ PR images built and pushed successfully! Images are available for testing (expires in 7 days):
|
@Fortune-Ndlovu tested all 5 scenarios + a new scenario (Qodo review no 4) where OKP flavor is enabled but base flavor IA default flavor is explicitly disabled - introduced requires config where OKP flavor defines this: |
Keep Intelligent Assistant enabled without OKP by default and provide an explicit OKP add-on flavour for OpenShift and Kubernetes. Add platform-specific documentation, generated manifests, and integration coverage. Preserve deterministic flavour merge precedence by applying unmentioned defaults first and explicitly configured flavours in CR declaration order. Co-authored-by: Codex <noreply@openai.com>
Rename the OKP Service and Route resources to use the Intelligent Assistant prefix, update generated manifests and integration coverage, and consolidate the OpenShift OKP guidance. Co-authored-by: Codex <noreply@openai.com>
Refine flavour ordering and validation, align the generated manifests, and update Intelligent Assistant OKP documentation and tests. Co-authored-by: Codex <noreply@openai.com>
97cbd88 to
78519cd
Compare
|
|
@gazarenkov @rm3l @Fortune-Ndlovu pls take a look, reviews addressed (all reviewers + all Qodo reviews from high to low) and rebased with main, thank you. |
|
✅ PR images built and pushed successfully! Images are available for testing (expires in 7 days):
|
There was a problem hiding this comment.
Similar to https://github.com/redhat-developer/rhdh-chart/blob/main/charts/rhdh/templates/intelligent-assistant/okp-deployment.yaml#L74-L84, it would be recommended to add some readiness and liveness probes to the OKP deployment. But can be addressed later.
33a0c87
into
redhat-developer:main
7 participants
Description
Add Offline Knowledge Portal (OKP) as an optional add-on flavour for Intelligent Assistant, building on the generic flavour templating and plugin-dependency infrastructure introduced by #3477.
intelligent-assistantexperience unchanged and enabled without OKP.intelligent-assistant-okpflavour that:okpdependency to the Intelligent Assistant backend plugin;OKP_SERVICE_URLwith its HTTP URL.OKP_SERVICE_URLto the user because the Operator does not manage Ingress.intelligent-assistant-okp-*resource prefix consistently for the OKP Deployment, Service, and Route.OKP remains disabled by default. The OKP image is large, so explicitly enabling it can make the first installation significantly slower while the image is downloaded.
Which issue(s) does this PR fix or relate to
https://redhat.atlassian.net/browse/RHIDP-16103
PR acceptance criteria
How to test changes / Special notes to the reviewer
Intelligent Assistant without OKP
Deploy a
BackstageCR with only the base flavour:Verify that RHDH and LCORE become ready and that no
intelligent-assistant-okp-*resources,OKP_SERVICE_URL, or OKP RAG configuration are present.OpenShift with OKP
Enable both flavours:
Verify:
Confirm that the OKP Deployment, Service, and Route are ready,
OKP_SERVICE_URLuses the generated HTTP Route, LCORE is ready, and Intelligent Assistant returns clickable OKP citations.Optional HTTPS configuration for a private OpenShift router CA is documented in
docs/intelligent-assistant-okp-openshift.md.Kubernetes with OKP
Enable both flavours, configure
registry.redhat.ioauthentication, create an Ingress, and inject its public URL asOKP_SERVICE_URL. Followdocs/intelligent-assistant-okp-kubernetes.mdfor the complete HTTP or HTTPS setup.Confirm that the OKP Deployment and Service are ready, LCORE can reach the configured Ingress, and citation links are reachable from the browser.
Validation performed
make lintmake local-dynamic-plugins && make testmake integration-test ARGS='--focus "create default rhdh"'make gosecmake bundles build-installers