-
Notifications
You must be signed in to change notification settings - Fork 22
Prompt change to reduce hallucinations of static net config #227
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
Prompt change to reduce hallucinations of static net config #227
Conversation
It should use the generate_nmstate_yaml call if it supports the given config instead of trying to figure it out on its own.
WalkthroughThe pull request updates template.yaml by adjusting indentation for an existing bullet and adding a new bullet instructing regeneration of NMState YAML via generate_nmstate_yaml when supported. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
template.yaml (2)
252-252: Don’t assume interface names; ask or discover instead.Defaulting to eth0/eth1 conflicts with the earlier “Don’t make assumptions” rule and with predictable interface names (enp/ens). Prefer confirming with the user or using discovered host inventory/mac-to-interface mapping via tools.
- * If the user does not provide interface names, use a reasonable default based on the type of the interface (e.g. for ethernet use eth0, eth1, etc). + * If the user does not provide interface names, do not guess. Ask the user, or use discovered host inventory (e.g., MAC-to-interface mapping) to determine the correct interface names before generating YAML.
255-257: Good: prefer generate_nmstate_yaml when possible. Add brief fallback guidance.This aligns with reducing hallucinations. Consider clarifying how to detect “supported” and the fallback path if the tool rejects inputs (e.g., NotSupported/validation error).
* If the config is supported by the generate_nmstate_yaml tool, use that to regenerate the yaml. + * Attempt the tool call first; if it indicates the request is unsupported or returns a validation error, fall back to carefully editing the nmstate YAML yourself, then validate with the tool before showing it to the user.
|
@keitwb: 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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: carbonin, keitwb The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
6667b84
into
rh-ecosystem-edge:main
It should use the generate_nmstate_yaml call if it supports the given config instead of trying to figure it out on its own.
Summary by CodeRabbit