Skip to content

Conversation

@bergmannf
Copy link
Contributor

This should allow AI tools to use osdctl to get some additional information.

Also refactors the context command to split the in-memory cache from the
actual commandline options.
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 27, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bergmannf

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

The pull request process is described here

Details 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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 27, 2025
@bergmannf bergmannf force-pushed the SREP-2141-add-mcp-server branch from fc6e4bf to d4e6319 Compare October 27, 2025 11:17
@RaphaelBut
Copy link
Contributor

looks pretty good to me
if you want you could separate the refactors and the mcp into two PRs :)

@bergmannf bergmannf force-pushed the SREP-2141-add-mcp-server branch 3 times, most recently from ded7834 to 0fc45f0 Compare October 27, 2025 15:19
@bergmannf bergmannf force-pushed the SREP-2141-add-mcp-server branch from 0fc45f0 to 8b78b2b Compare October 27, 2025 16:07
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 27, 2025

@bergmannf: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.

@bergmannf
Copy link
Contributor Author

looks pretty good to me if you want you could separate the refactors and the mcp into two PRs :)

I felt that the changes I made would be way uglier if I didn't refactor as well, as all our commands make everything private and make it unnecessarily hard to call them from elsewhere.

If you feel strongly about it I can split the PR though.

@joshbranham
Copy link
Contributor

looks pretty good to me if you want you could separate the refactors and the mcp into two PRs :)

I felt that the changes I made would be way uglier if I didn't refactor as well, as all our commands make everything private and make it unnecessarily hard to call them from elsewhere.

If you feel strongly about it I can split the PR though.

I have always wanted to slowly push our cmd/ packages to be thin and move all the business logic into pkg/cluster/context (for example) type packages. Then the CLI is a small shim over calling actual exported code that could be consumed by other projects, vs them calling our CLI functions.

Do with that what you will, by no means saying you have to, but figured I'd mention it.

@bergmannf
Copy link
Contributor Author

looks pretty good to me if you want you could separate the refactors and the mcp into two PRs :)

I felt that the changes I made would be way uglier if I didn't refactor as well, as all our commands make everything private and make it unnecessarily hard to call them from elsewhere.
If you feel strongly about it I can split the PR though.

I have always wanted to slowly push our cmd/ packages to be thin and move all the business logic into pkg/cluster/context (for example) type packages. Then the CLI is a small shim over calling actual exported code that could be consumed by other projects, vs them calling our CLI functions.

Do with that what you will, by no means saying you have to, but figured I'd mention it.

Absolutely - essentially I'd like the CLI to really be the thinnest layer of input - essentially right now we have all the logic in the view layer of MVC and the goal should be moving to the C layer (which we don't have).
This was really just a quick refactor to make it less ugly to expose it for now.

@bergmannf
Copy link
Contributor Author

/hold
I am holding this for now as there are guidelines form the ProdSec team coming along we want to make sure we adhere with before merging and releasing this.

@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 Nov 6, 2025
@openshift-merge-robot
Copy link
Contributor

PR needs rebase.

Details

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.

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants