CONSOLE-5118: Add OLS integration for cluster update workflows#16131
CONSOLE-5118: Add OLS integration for cluster update workflows#16131fao89 wants to merge 1 commit intoopenshift:mainfrom
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@fao89: This pull request references CONSOLE-5118 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
Bot
added
component/core
|
@fao89: This pull request references CONSOLE-5118 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
📝 WalkthroughWalkthroughThis pull request integrates LightSpeed/OpenShift Console (OLS) support into the cluster settings UI. A new 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@frontend/public/components/cluster-settings/cluster-settings.tsx`:
- Around line 1494-1511: The precheck prompt in the case 'precheck' block uses
availableUpdates[0] (targetVersion) which may be undefined or misleading before
a user selects a release; change the logic in the cluster-settings.tsx precheck
handler to stop hard-coding availableUpdates[0]: if there is a user-selected
target (e.g., selectedRelease or selectedUpdate state), use that version
(targetVersion) in the prompt; otherwise construct a version-agnostic prompt
that either lists all candidate versions (map availableUpdates to their .version
strings) or explicitly states that no single target is selected and asks for
guidance across the candidate set; update the same pattern referenced around
lines 1646-1649 as well.
- Around line 979-982: The current render condition treats
ClusterUpdateStatus.ErrorRetrieving like a failure and shows the "Add Failure
OLS Button"; remove ClusterUpdateStatus.ErrorRetrieving from the failure branch
so the button only appears for ClusterUpdateStatus.Failing and
ClusterUpdateStatus.UpdatingAndFailing, and add a separate branch for
ClusterUpdateStatus.ErrorRetrieving that either hides the button or renders a
distinct retrieval-error UI/prompt (create a small conditional branch near the
existing button rendering using the status variable and
ClusterUpdateStatus.ErrorRetrieving to present a dedicated message/component
instead of the failure workflow).
- Around line 1921-1933: The health check for operators wrongly uses
op.status?.conditions?.every(...) which treats unrelated conditions (e.g.,
Upgradeable) as failures; update the logic in the operatorHealth calculation
(and the similar block around allOperatorsHealthy) to explicitly pick conditions
by type ('Available','Progressing','Degraded') from op.status.conditions (use
find or a small lookup) and then evaluate only those three for the healthy
determination, leaving allOperatorsUpdated logic (getClusterOperatorVersion and
getCurrentVersionSafe) unchanged; modify the code paths that compute
operatorHealth.healthy and allOperatorsHealthy to reference these explicit
condition checks for each clusterOperators element.
- Around line 900-909: Gate the ClusterOperator and Node watches behind the
OLS-availability flag so they only mount when the OLS action is actually shown:
keep the hook calls (useK8sWatchResource) in place but pass null (or an explicit
disabled value) instead of the resource descriptor when the existing OLS
availability flag (e.g., canShowOlsAction / isOlsAvailable / whatever boolean
you already compute to decide showing the OLS action) is false; update the two
calls that create clusterOperators/clusterOperatorsLoaded and nodes/nodesLoaded
(currently using ClusterOperatorModel and NodeModel) to use a conditional
argument (shouldWatch ? { isList: true, kind:
referenceForModel(ClusterOperatorModel) } : null) and similarly for NodeModel so
the watches only start when OLS is available.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bcb67d8d-d4a9-420b-b922-e44673df8830
📒 Files selected for processing (2)
frontend/public/components/cluster-settings/cluster-settings.tsxfrontend/public/locales/en/public.json
| case 'precheck': { | ||
| const targetVersion = availableUpdates[0]?.version; | ||
| const recentFailures = | ||
| cv.status?.history?.slice(0, 5).filter((h) => h.state !== 'Completed').length || 0; | ||
|
|
||
| return `I'm planning to update my ${environment} OpenShift cluster (${clusterSize}) from ${currentVersion} to ${targetVersion} via ${updateChannel} channel. | ||
|
|
||
| Recent update history shows ${recentFailures} non-successful attempts in the last 5 updates. | ||
|
|
||
| Please provide comprehensive pre-update guidance including: | ||
| 1. Specific prerequisites and compatibility checks for this version jump | ||
| 2. Resource requirements and capacity planning | ||
| 3. Backup and rollback strategies | ||
| 4. Risk assessment based on my cluster configuration | ||
| 5. Estimated update duration and maintenance window planning | ||
| 6. Any known issues or breaking changes for this update path | ||
|
|
||
| Focus on actionable steps I should take before starting the update.`; |
There was a problem hiding this comment.
Don't hard-code availableUpdates[0] as the precheck target.
This action is rendered before the user selects a release, but the prompt and attachment pretend a specific target version was chosen. On clusters with multiple supported updates, OLS can analyze the wrong upgrade path and return incorrect prerequisite guidance. Either make the precheck flow version-specific after selection, or keep it version-agnostic and send the full candidate set.
Also applies to: 1646-1649
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@frontend/public/components/cluster-settings/cluster-settings.tsx` around
lines 1494 - 1511, The precheck prompt in the case 'precheck' block uses
availableUpdates[0] (targetVersion) which may be undefined or misleading before
a user selects a release; change the logic in the cluster-settings.tsx precheck
handler to stop hard-coding availableUpdates[0]: if there is a user-selected
target (e.g., selectedRelease or selectedUpdate state), use that version
(targetVersion) in the prompt; otherwise construct a version-agnostic prompt
that either lists all candidate versions (map availableUpdates to their .version
strings) or explicitly states that no single target is selected and asks for
guidance across the candidate set; update the same pattern referenced around
lines 1646-1649 as well.
|
/test e2e-gcp-console |
CI Status UpdateAll core builds are passing consistently:
The e2e failures appear to be environment-related (resource constraints, networking issues, cluster instability) rather than code-related. The test logs show good initial execution but infrastructure failures. Requesting maintainer review for merge consideration given the clean core builds. /cc @console-maintainers |
|
@fao89: This pull request references CONSOLE-5118 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-merge-robot
added
the
needs-rebase
openshift-merge-robot
removed
the
needs-rebase
fao89
force-pushed
the
CONSOLE-5118
branch
2 times, most recently
from
9152d86 to
93ce038
Compare
openshift-ci
Bot
added
component/dashboard
fao89
force-pushed
the
CONSOLE-5118
branch
2 times, most recently
from
29f7400 to
1c5ee73
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: fao89 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
fao89
force-pushed
the
CONSOLE-5118
branch
3 times, most recently
from
5edd11d to
556cc2d
Compare
fao89
force-pushed
the
CONSOLE-5118
branch
2 times, most recently
from
ae21944 to
f638fd3
Compare
fao89
force-pushed
the
CONSOLE-5118
branch
2 times, most recently
from
d1b9e55 to
7b2c7de
Compare
|
/retest-required |
TheRealJon
left a comment
TheRealJon
left a comment
There was a problem hiding this comment.
Overall, this is really good! The comments are mostly nits that will help make this easier to read and maintain. Thanks @fao89!
I would recommend going through the React and Typescript docs and other resources to learn more about best practices and anti-patterns. Also, make sure to review for type definitions on on anything that can't be inferred. I probably didn't call out every missing or incorrect type definition.
| value: safeDump(data, { indent: 2, lineWidth: -1 }), | ||
| kind: data?.kind || 'Resource', | ||
| }); | ||
|
|
There was a problem hiding this comment.
We strongly discourage the use of the any type because it weakens overall type safety and can hide bugs that could have been caught at build time with stronger type definitions.
| /** | ||
| * Cluster version helpers specific to update workflows | ||
| */ | ||
| export const createUpdateClusterVersionHelpers = ( |
There was a problem hiding this comment.
I would recommend individual helpers or hooks rather than a factory. In general, it's better to err on the side of smaller, targeted helpers in React. This can help insulate against hot looping or efficiency issues. Since the React lifecycle is a render loop, one update can trigger a waterfall of unintended re-renders.
| @@ -339,6 +343,43 @@ const ClusterUpdateModal = (props: ClusterUpdateModalProps) => { | |||
| data-test="update-cluster-modal-partial-update-radio" | |||
| /> | |||
| </FormGroup> | |||
| {/* OLS Update Precheck Section */} | |||
| {useFlag('LIGHTSPEED_CONSOLE') && desiredVersion && ( | |||
There was a problem hiding this comment.
Can't use a hook inside a hook. Store the value of useFlag in a const hoisted near the top of this component, then use that value here.
fao89
force-pushed
the
CONSOLE-5118
branch
11 times, most recently
from
ea033fb to
1d59aba
Compare
fao89
force-pushed
the
CONSOLE-5118
branch
2 times, most recently
from
780afb0 to
8d3032a
Compare
TheRealJon
left a comment
TheRealJon
left a comment
There was a problem hiding this comment.
Hi @fao89! Could you provide some detailed instructions on how to test your changes?
Also had a few more comments.
|
@fao89: This pull request references CONSOLE-5118 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
Implements OpenShift Lightspeed AI assistance integration into cluster settings page to provide contextual help during cluster update workflows. Features: - UpdateWorkflowOLSButton component with 4 workflow phase support - Precheck: Pre-update validation and readiness assessment - Failure: Error analysis and troubleshooting guidance - Status: Real-time update progress monitoring assistance - Success: Post-update verification and validation help The integration uses the official lightspeed-console plugin API to open the OLS chatbox with context-aware prompts and cluster data attachments. Each workflow phase provides tailored AI prompts and exports relevant cluster resources (ClusterVersion) as YAML for comprehensive analysis. Co-Authored-By: Claude Sonnet 4 Signed-off-by: Fabricio Aguiar <fabricio.aguiar@gmail.com>
|
@fao89: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
8 participants
Depends-On: openshift/lightspeed-console#1793
Implements OpenShift Lightspeed AI assistance integration into cluster settings page to provide contextual help during cluster update workflows.
Features:
The integration uses the official lightspeed-console plugin API to open the OLS chatbox with context-aware prompts and cluster data attachments. Each workflow phase provides tailored AI prompts and exports relevant cluster resources (ClusterVersion) as YAML for comprehensive analysis.
https://github.com/openshift/lightspeed-console?tab=readme-ov-file#opening-the-openshift-lightspeed-ui-from-other-console-pages-and-plugins
Summary by CodeRabbit
New Features
Localization