* refactor(kubernetes): Provider implementations deal with Manager instantiations
Removed `*Manager` parameter from `ProviderFactory`.
Provider implementations should deal with the appropriate (base) Manager instantiation
if needed at all.
Manager creation function divided into two explicit functions:
- NewKubeconfigManager: to be used when using KubeConfig files
- NewInClusterManager: to be used inside a cluster
New functions contain validations to ensure they are used in the expected places.
This ensures that the right manager is used by the provider implementation.
Fake kubeconfig for in-cluster Manager is now generated when the Manager is created.
This kubeconfig has the "magic" strings (inClusterKubeConfigDefaultContext) that are
used by the MCP server and tool mutators.
Signed-off-by: Marc Nuri <marc@marcnuri.com>
* review: Provider implementation refactor
Signed-off-by: Marc Nuri <marc@marcnuri.com>
---------
Signed-off-by: Marc Nuri <marc@marcnuri.com>
* refactor(kubernetes): streamline provider configuration and in-cluster detection
- Removed IsInCluster method from Manager and created function scoped to the runtime environment.
As a method, the implementation was not correct.
Removed GetAPIServerHost method from Manager which is no used.
- **Temporarily** added an `inCluster` field to the Manager struct but should be eventually removed since it doesn't really make sense to hava a Manager in-cluster or out-of-cluster in the multi-cluster scenario.
- Provider resolution (resolveStrategy) is now clearer, added complete coverage for all scenarios.
- Added additional coverage for provider and manager.
Signed-off-by: Marc Nuri <marc@marcnuri.com>
* refactor(kubernetes): update NewManager to accept kubeconfig context and simplify manager creation
- Removes Provider.newForContext(context string) method.
Signed-off-by: Marc Nuri <marc@marcnuri.com>
---------
Signed-off-by: Marc Nuri <marc@marcnuri.com>
* refactor(kubernetes): keep Provider as only external Kubernetes interface
Initial phase to unify-merge the Provider interface with the Manager struct.
- Renamed ManagerProvider to Provider (i.e. kubernets.Provider)
- Moved Manager related logic to specific files
- Exposed relevant method through Provider interface (GetDerivedKubernetes, IsOpenShift, VerifyToken)
Signed-off-by: Marc Nuri <marc@marcnuri.com>
* Update pkg/kubernetes/provider_kubeconfig.go
Co-authored-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Marc Nuri <marc@marcnuri.com>
---------
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Co-authored-by: Calum Murray <cmurray@redhat.com>
Prevents protocol issues with some clients.
Kubernetes tooling uses klog to log messages.
Some of these messages end up logged in the stderr or stdout which breaks some of the clients that expect jsonrpc messages.
Signed-off-by: Marc Nuri <marc@marcnuri.com>
- Refactor tests to use testify (more clarity+composability for complex tests)
- Tests for default toolsets
- Tests for configured, granular toolsets
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Users can now enable or disable different toolsets either by providing
a command-line flag or by setting the toolsets array field in the TOML
configuration.
Downstream Kubernetes API developers can declare toolsets for their
APIs by creating a new nested package in pkg/toolsets and registering
it in pkg/mcp/modules.go
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Initial PR to make the toolsets agnostic of the usd MCP implementation (migration to go-sdk).
The decoupling will also be needed to move the different toolsets to separate nested packages (toolsets).
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Add 'previous' parameter to pods_log tool to retrieve logs from terminated containers, equivalent to kubectl logs --previous functionality.
This enables debugging of containers that have restarted due to crashes or updates.
Signed-off-by: Samuel Masuy <samuel.masuy@goto.com>
Co-authored-by: opencode <noreply@opencode.ai>
As a prior step to providing support for toolsets
this change repurposes the current work in profiles
which partially aligns with the toolsets expected features
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Adds DisableDynamicClientRegistration and OAuthScopes to be able to override
the values proxied from the configured authorization server.
DisableDynamicClientRegistration removes the registration_endpoint field from
the well-known authorization resource metadata.
This forces VSCode to show a for to input the Client ID and Client Secret since
these can't be discovered.
The OAuthScopes allows to override the scopes_supported field.
VSCode automatically makes an auth request for all of the
supported scopes.
In many cases, this is not supported by the auth server.
By providing this configuration, the user (MCP Server administrator)
is able to set which scopes are effectively supported and
force VSCode to only request these.
Signed-off-by: Marc Nuri <marc@marcnuri.com>
It's unclear how the scopes are going to be populated in the JWT.
Disable scope authorization for the time being.
Signed-off-by: Marc Nuri <marc@marcnuri.com>
