Proposal for donating streamshub-mcp to Strimzi org - #11
Conversation
Signed-off-by: Jakub Stejskal <xstejs24@gmail.com>
MikeEdgar
left a comment
MikeEdgar
left a comment
There was a problem hiding this comment.
Looks good to me. I just have one comment/question about the common components.
| - **Metrics** — `MetricsProvider` interface with provider selection via `mcp.metrics.provider` configuration. | ||
| - **Logs** — `LogCollectorProvider` interface with provider selection via `mcp.log.provider` configuration. |
There was a problem hiding this comment.
I'm not familiar enough with specifically these do, but quickly looking at them I wonder if these metrics and log collector interfaces/providers would be good candidates as their own stand-alone components? I suppose that would complicate the process of moving the MCP server though.
There was a problem hiding this comment.
interfaces are part of common module, and both providers are planned to be released as standalone packages. I think it is written few lines forward.
There was a problem hiding this comment.
Yes, we just do not plan to have them in separated repository for now, but this might change in the future.
tomncooper
left a comment
tomncooper
left a comment
There was a problem hiding this comment.
I had a few initial comments.
Generally, I don't think this is strictly needed or a priority, but I am not going to block it if it is what the majority of maintainers want.
Also, are there any specific licensing or other legal requirements for donating a software project to a CNCF project?
|
|
||
| ## Motivation | ||
|
|
||
| - The Strimzi community has expressed interest in adopting the MCP server as part of the Strimzi ecosystem. |
There was a problem hiding this comment.
Do you have any links to issues/comments/discussions for this interest?
There was a problem hiding this comment.
There was discussion directly on StrimziCon where we had a presentation about MCP.
Then there are few messages on Strimzi slack
https://cloud-native.slack.com/archives/CMH3Q3SNP/p1781587329036659?thread_ts=1781263622.033449&cid=CMH3Q3SNP
https://cloud-native.slack.com/archives/CMH3Q3SNP/p1785425543644589
Also there were discussions between Strimzi maintainers around MCP server.
| ## Motivation | ||
|
|
||
| - The Strimzi community has expressed interest in adopting the MCP server as part of the Strimzi ecosystem. | ||
| - The MCP server is Strimzi-specific tooling — hosting it under the Strimzi organization provides better alignment with its primary domain. |
There was a problem hiding this comment.
Its Strimzi specific right now, but that was only ever supposed to be the starting point. Like you say below, we were planning to add Kafka in the near future and potentially targeting other tools in future.
How will this donation effect the ability to integrate with other tools and provide a joined up solution for users of out stack?
There was a problem hiding this comment.
That's more question for upcoming Strimzi proposals. However, the common parts (common module, metrics-prometheus and logs-loki modules) will be released to maven central so Kafka MCP can use it and it doesn't matter where it will be hosted. I would like to have Kafka MCP next to Strimzi one as it will provide additional information that Strimzi will not collect through Kafka Admin API. I think this Kafka MCP server could be run also as a standalone application, not just on OpenShift (similar to Kafka Bridge).
|
|
||
| - **Metrics** — `MetricsProvider` interface with provider selection via `mcp.metrics.provider` configuration. | ||
| - **Logs** — `LogCollectorProvider` interface with provider selection via `mcp.log.provider` configuration. | ||
| - **Auth** — currently not implemented, but users has to have option to replace auth & authz mechanism with their own implementation. |
There was a problem hiding this comment.
On the AuthZ front, I was hoping we could standardise on a common Authorizer API for our components (potentially the one provided by Kroxylicious - details in #5). The reason I bring that up is that, subject to my upcoming proposal on this, it would be good to have the StreamsHub MCP use this API (whatever it ends up being) so it can be integrated easily with all the other StreamsHub components.
I worry that once it is donated to Strimzi, it might be hard to get a unified AuthZ approach (that aligns with StreamsHub's goals) included. To put it frankly, it would be easier if we made those changes before we donated, so they are baked in.
Maybe this is not such an issue for the Strimzi MCP (as it uses K8s RBAC for AuthZ) but it would be for the Kafka and other potential MCPs. Indeed, that might be an argument for developing them in StreamsHub rather than Strimzi.
There was a problem hiding this comment.
This might be a valid concern, but as long as the Authorizer API will be in separated module with zero external dependencies as it stated in the issue, I do not see it as a big problem to use it even after moving MCP to Strimzi.
We have couple of options:
- continue with donating efforts and use it for authz within Strimzi org (argument for using it could be that Apicurio Registry, another CNCF project, is going to use it as well which will enhance the UX)
- postpone the donation until Authorizer API proposal and implementation will be merged and we can implement it in our MCPs (currently we do not use any authz mechanism as you mentioned so I do think we should go this way, we don't know how Kafka MCP will look like and it will require separated proposal wherver it will land)
- stop the donation and wait couple of months to see if there will be more demands from Strimzi or StreamsHub communities and meanwhile implement whatever we will need
Even for Strimzi MCP we will probably need it at some point, because from my POV we will need to implement Kubernetes impersonation and make it able to work together with external oauth servers like Keycloak. So the question is if we want to stop it for not sure how long or simply move the code, benefit from wider Strimzi community and possibly direct Strimzi integration.
There was a problem hiding this comment.
This can be also stated in the Strimzi proposal that we would like to adopt Authorizer API interface at some point.
|
|
||
| ## Compatibility | ||
|
|
||
| Existing users of the MCP server are not affected. |
There was a problem hiding this comment.
At all? Won't the image addresses and package names change?
There was a problem hiding this comment.
Well yes, they will need to update at some point to newer images with different paths where packages will be named differently. I didn't consider this as a problem, but I am happy to mention it there. Do you have any specific parts that should be mentioned?
I received info from CNCF - as long as we will not transfer any logos, names, or domains, we can treat is as regular code contribution. |
4 participants
This is just a formal proposal on StreamsHub site. Approval of this proposal doesn't guarantee that MCP will be accepted by Strimzi org. This has to be covered by additional proposal on Strimzi side.