Generating suggested CR changes

[jturenov]

Proposed feature

1. Recommendations when Console detects something actionable, e.g.: Cluster imbalance ("This cluster is unbalanced — rebalancing is recommended")

• Under-provisioned / over-provisioned brokers
• High CPU usage on one or more brokers
• Disk space running low / approaching capacity
• A rebalance that's been pending too long

2. Adds a one-click action next to each recommendation that creates a pre-filled GitOps issue/task (e.g. in the relevant streamshub-gitops repo) containing: cluster name, detected condition, timestamp, and suggested action.

[alexcreasy]

I think the core idea of generating e.g. a KafkaRebalance CR for the user is a good one and would be highly useful.

In my opinion trying to automatically create an issue for this on the user's behalf has a number of problems that make it less favourable. The biggest problem I see is the console having to store sensitive credentials for the issue tracking system in order to be able to open a ticket.

A second issue is, how many issue trackers do we support? GitHub, GitLab, JIRA, others - if we don't support the issue tracker their team use the feature isn't of any use to them.

As a side note the streamshub-gitops repo is just a set of examples specific to streams. In reality anyone using production GitOps will likely have a repository for their entire application's infrastructure; of which the Kafka based stuff will be only a part.

[tomncooper]

On point 1:

The issue with having the console do recommendation of changes to the Kafka cluster is that, particularly in the case of rebalances, it would often conflict with existing or proposed Strimzi features. In the case of rebalances, Strimzi will soon support auto-rebalancing (see accepted this proposal which is currently being implemented) which would make a console based system redundant.

The idea of a system that could audit a Kafka CR (and other Streamshub related CRs/configs) is an interesting one, but we would have to come up with misconfigurations which Strimzi itself misses/ignores and are not caught by Cruise Control. Such a system could be part of the MCP or agentic skills, but could also be a standalone audit tool. I don't think such a tool, if we built it, should be part of the console exclusively as users who don't run the console/mcp could benefit from it too.

On point 2:

I agree with @alexcreasy, this would be a very hard feature to implement in practice. The credential management for ticketing systems would be undesirable.

On the gitops front, the issue is that the layout of the gitops system a user's org implements could take pretty much any form: One monorepo for the entire org, one repo per sub-org, one repo per environment, one repo per application and so on. Even assuming you can figure out where to apply a given change, we would then need to reason about directory structure, templating/overlays (helm, kustomize, etc) and many other things.

I think the best option, from the console point of view, is to suggest to/guide the user in what CRs to change/create, give example config text and then leave it up to them (or an agent with access to the gitops setup) to apply the change.