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.

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

OLS-1379: Add oc tools #2216

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

OLS-1379: Add oc tools #2216

wants to merge 1 commit into from

Conversation

onmete
Copy link
Contributor

@onmete onmete commented Feb 7, 2025

Description

Adding oc tools.

OLS-1410

Type of change

  • New feature

@onmete onmete marked this pull request as draft February 7, 2025 08:50
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Feb 7, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Feb 7, 2025

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

In response to this:

Description

Adding oc tools.

Type of change

  • New feature

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 openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 7, 2025
Copy link

openshift-ci bot commented Feb 7, 2025

[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 xrajesh for approval. For more information see the Code Review Process.

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

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

@onmete
Copy link
Contributor Author

onmete commented Feb 7, 2025

@asamal4 this should be easy to integrate once you have your PR ready.
I've put there a shot of tools per oc command as we discussed.
I'll add tests later (in this PR), once we conclude the right approach.

@onmete
Copy link
Contributor Author

onmete commented Feb 7, 2025

/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 7, 2025
raise e


def oc_get(args: list[str]) -> subprocess.CompletedProcess:
Copy link
Contributor

Choose a reason for hiding this comment

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

input type: Why it is list[str] ? shouldn't it be just str ?
output type: I haven't tested, but I am thinking we can keep this as str (we can convert the output to str)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup, output should be a string.
As for the input, technically it is a list of strings. From my experiments, llm had no issue returning it, but I'll try to double-check what is better understandable to the llm (list of strings/one string).

# List one or more resources by their type and names.
oc get rc/web service/frontend pods/web-pod-13je7
"""
result = run_oc(["get", *sanitize_oc_args(args)])
Copy link
Contributor

Choose a reason for hiding this comment

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

What will be the args value ? part of the command except oc get ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, besides sanitization, we can also catch the case when llm returns not just the args, but the full command oc get whatever instead of just whatever.

Copy link
Contributor

Choose a reason for hiding this comment

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

Probably we are relying too much on model to generate the command here. Also this will require us to handle lot of corner cases (lot of rules to sanitize).
Anyways let's see if others have any opinion on this.

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 18, 2025
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 19, 2025
@onmete
Copy link
Contributor Author

onmete commented Feb 19, 2025

@asamal4 @tisnik I've pushed the oc tools. Check it out please, I'll add tests later (not e2e for tools).

@onmete onmete marked this pull request as ready for review February 20, 2025 11:29
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 20, 2025
@onmete
Copy link
Contributor Author

onmete commented Feb 20, 2025

/assign @asamal4

@openshift-ci-robot
Copy link

openshift-ci-robot commented Feb 20, 2025

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

In response to this:

Description

Adding oc tools.

OLS-1410

Type of change

  • New feature

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 openshift-ci bot requested a review from xrajesh February 20, 2025 11:30
is_final_round: bool,
) -> tuple[AIMessage, TokenCounter]:
"""Invoke LLM with or without tools based on conditions."""
llm = (
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps nitpicking, but can we add this condition to _invoke_llm method itself. We can avoid additional lines of code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

return {}

logger.info("Introspection enabled - using default tools selection")
tools_map: dict = {} # place for other/default tools
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to have this here ?
in tools.py file we are defining all tools. Default can also be added there.
This will also help us not to have separate description len check.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

@asamal4
Copy link
Contributor

asamal4 commented Feb 24, 2025

We discussed about identifying different test scenarios. But for time being could you please modify e2e test case (just one). So that once introspectionEnabled property, any can simply un-comment the tool calling e2e test suites.

Test any one query for which you don't have to do additional set up.
Test with all 3 provider/models that we are actively testing and modify the response. So that test case will work for all.

@onmete
Copy link
Contributor Author

onmete commented Feb 24, 2025

@asamal4 About the e2e, I would rather do that in a separate PR or after we figure out how to test the tools.
Is there a specific reason why you want it to happen here?

@@ -1,7 +1,7 @@
[tool.ruff]

# description of all rules are available on https://docs.astral.sh/ruff/rules/
lint.select = ["D", "E", "F", "W", "C", "S", "I", "G", "TCH", "SLOT", "RUF", "C90", "N", "YTT", "ASYNC", "A", "C4", "T10", "PGH", "FURB", "PERF", "AIR", "NPY", "FLY", "PLW2901"]
lint.select = ["D", "E", "F", "W", "C", "S", "I", "G", "TCH", "SLOT", "RUF", "C90", "N", "YTT", "ASYNC", "A", "C4", "T10", "FURB", "PERF", "AIR", "NPY", "FLY", "PLW2901"]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've removed the PGH from linting - when we want to ignore some error (eg. false positive) we can do that just by # type: ignore instead of writing down specific - especially in cases when there are more errors in one line.
cc @tisnik

@asamal4
Copy link
Contributor

asamal4 commented Feb 24, 2025

@asamal4 About the e2e, I would rather do that in a separate PR or after we figure out how to test the tools. Is there a specific reason why you want it to happen here?

Separate PR is fine.. BTW I am only requesting to update the existing one e2e test case.

I am not sure how much time we will take to figure out all the scenarios. But we can still enable tool calling e2e test case, once operator adds the flag (This will happen before we figure out scenarios). This is just to make sure that tool calling is working. I believe we need to make sure that things are working. And this is the reason we have added rhelai test flow with openai url.
Later we can modify or add more test cases based on final conclusion regarding how we want to test.

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 24, 2025
@onmete
Copy link
Contributor Author

onmete commented Feb 24, 2025

@asamal4 Updated the question, is this what you were after?

@asamal4
Copy link
Contributor

asamal4 commented Feb 25, 2025

@asamal4 Updated the question, is this what you were after?

Yes. Thank you. Most likely it is going to fail for granite. But we can deal with that in separate PR.
lgtm
Please rebase.

@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 25, 2025
@asamal4
Copy link
Contributor

asamal4 commented Feb 25, 2025

Based on testing, we will update the tool definition.
Improving granite is also a separate effort.
lgtm as far as this PR is concerned.
/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 25, 2025
if char in blocked_chars:
# stop processing further characters in this argument
logger.warning(
"Problematic character(s) found in oc tool argument '%s'", arg
Copy link
Contributor

Choose a reason for hiding this comment

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

probably we should stop processing such input as is, not try to sanitize it further

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we'll tackle this in OLS-1443

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Feb 25, 2025
Copy link

openshift-ci bot commented Feb 25, 2025

New changes are detected. LGTM label has been removed.

Copy link

openshift-ci bot commented Feb 25, 2025

@onmete: all tests passed!

Full PR test history. Your PR dashboard.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants