OLS-2673: Add query mode field to support different response styles

[onmete]

Description

Add a mode field to the OLS query API to support different response styles. Two modes are defined in a QueryMode enum:

• ask (default) — existing behavior, concise factual answers
• troubleshooting — placeholder for diagnostic-focused responses (prompt not yet implemented)

The mode is accepted in LLMRequest, threaded through ProcessedRequest, and the only runtime effect is which system prompt QueryHelper selects. All other pipeline behavior (RAG, tool calling, caching, streaming, quota) is unchanged.

The mode is also recorded in transcript metadata for observability.

Note: The troubleshooting system prompt is a placeholder ("NOT IMPLEMENTED"). This PR is opened as a draft until the prompt is finalized.

Type of change

• New feature

Related Tickets & Documents

• https://issues.redhat.com/browse/OLS-2673

Checklist before requesting a review

• I have performed a self-review of my code.
• PR has passed all pre-merge test jobs.
• If it is a core feature, I have added thorough tests.

Testing

• Unit tests added for model validation (test_models.py): default mode, explicit values, string coercion, invalid values
• Unit tests added for prompt selection (test_query_helper.py): ASK mode, TROUBLESHOOTING mode, config override precedence, default behavior
• Unit test added for end-to-end propagation (test_ols.py): verifies mode reaches DocsSummarizer.__init__
• Existing test_store_transcript updated to assert mode appears in transcript metadata
• All tests pass locally via uv run pytest

Made with Cursor

[openshift-ci-robot]

@onmete: This pull request references OLS-2673 which is a valid jira issue.

Details

In response to this:

Description

Add a mode field to the OLS query API to support different response styles. Two modes are defined in a QueryMode enum:

• ask (default) — existing behavior, concise factual answers
• troubleshooting — placeholder for diagnostic-focused responses (prompt not yet implemented)

The mode is accepted in LLMRequest, threaded through ProcessedRequest, and the only runtime effect is which system prompt QueryHelper selects. All other pipeline behavior (RAG, tool calling, caching, streaming, quota) is unchanged.

The mode is also recorded in transcript metadata for observability.

Note: The troubleshooting system prompt is a placeholder ("NOT IMPLEMENTED"). This PR is opened as a draft until the prompt is finalized.

Type of change

• New feature

Related Tickets & Documents

• https://issues.redhat.com/browse/OLS-2673

Checklist before requesting a review

• I have performed a self-review of my code.
• PR has passed all pre-merge test jobs.
• If it is a core feature, I have added thorough tests.

Testing

• Unit tests added for model validation (test_models.py): default mode, explicit values, string coercion, invalid values
• Unit tests added for prompt selection (test_query_helper.py): ASK mode, TROUBLESHOOTING mode, config override precedence, default behavior
• Unit test added for end-to-end propagation (test_ols.py): verifies mode reaches DocsSummarizer.__init__
• Existing test_store_transcript updated to assert mode appears in transcript metadata
• All tests pass locally via uv run pytest

Made with Cursor

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]

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

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign tisnik for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[blublinsky]

Although proposed approach will work, I think we need additional discussion on this.
Current implementation is not easily extensible. Adding any additional mode will require opening up the code, both the server and UI. In my opinion a much better, more extensible approach is to do modes via configuration. This will mean the following:

1. Add configuration dictionary - mode/prompt. This should include the current prompt
2. Create an additional endpoint for UI to get a list of configured modes. This can be used for populating drop down
3. Use what is implemented in this PR to propagate mode and pick corresponding prompt.

With this in place OLS will be fully configurable by users for the set of modes/promptes with NO changes to the OLS code.

[blublinsky]

Why do we need this in response?

[onmete]

You mean in response or DocsSummarizer (where is this comment attached)?

[blublinsky]

response

[onmete]

It is not in the response. It is in ProcessedRequest, not the one we return (LLMResponse).

[blublinsky]

There is a certain asymmetry here. Default prompt (ask) is overwritable (can be configured through CR), and troubleshooting one?

[onmete]

Not now.

[onmete]

/retest

[openshift-ci]

@onmete: all tests passed!

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-sigs/prow repository. I understand the commands that are listed here.

[onmete]

/retest