helm tool

[sahil-lakhwani]

I've been using kubectl-ai while working with Helm charts and realized that, similar to how kubectl and bash tools, a helm tool would be useful. I started drafting one here: https://github.com/sahil-lakhwani/kubectl-ai/blob/helm-ai/pkg/tools/helm_tool.go

I'm wondering if it makes sense to include this as part of kubectl-ai, or if it would be better suited as a separate plugin or tool.

[hakman]

I am all for that. I was also thinking of adding jq for similar reasons.

[sahil-lakhwani]

Thanks! I'll come up with a PR soon.

[hakman]

@droot @justinsb any thoughts?

[droot]

Quick comment: on a high level, we need to find a solution for, how do users make tools other than built-in available to the kubectl-ai. Even for built-in tools, how to allow/disallow tools. In the industry, people are adopting mcp (model-context-protocol) to plug tools, so mcp-client integration will be one way to address this gap, however, I do think we can offer something simpler for CLI tools (imagine kubectl-ai maintaining cache of executable tools) but need some experimentation.

Also, we make bash tool available to kubectl-ai today and that sort of makes any CLI tool available to kubectl-ai. I have seen kubectl-ai running composite commands that involve jq, wc etc without adding tools such as jq.

@sahil-lakhwani I am curious what was your exact use-case ? I wonder if LLM could use bash tool to execute helm ?

Something related, I wonder if, additional tweaks to the prompt can solve this. See https://github.com/GoogleCloudPlatform/kubectl-ai/issues/204 https://github.com/GoogleCloudPlatform/kubectl-ai/pull/205

[sahil-lakhwani]

I was exploring use cases where kubectl and helm need to work together — for example, when a ConfigMap or Secret needs to be created with kubectl before installing a Helm chart.

I'm still unclear on how much difference there is between having the AI model generate Helm commands through the generic bash tool versus a dedicated helm tool.

That said, I assume having a separate helm tool could provide a more structured interface and make it easier to extend or customize Helm-specific behavior going forward?

[sahil-lakhwani]

Above said, it does sounds good to have a way for users to optionally provide tools at runtime instead of adding everything to builtin tools.

[droot]

I was exploring use cases where kubectl and helm need to work together — for example, when a ConfigMap or Secret needs to be created with kubectl before installing a Helm chart.

would be great if someone can try it out and see where the gap really is...

[janetkuo]

@sahil-lakhwani I've added support for custom tools: https://github.com/GoogleCloudPlatform/kubectl-ai/pull/223 Would you give it a try?

[janetkuo]

We've added custom tools usage to README: https://github.com/GoogleCloudPlatform/kubectl-ai?tab=readme-ov-file#tools

[sahil-lakhwani]

Sure @janetkuo, I'll give it a try