[PREVIEW] Start MCP server when OpenStack deployment is present#92
Draft
lpiwowar wants to merge 6 commits into
Draft
[PREVIEW] Start MCP server when OpenStack deployment is present#92lpiwowar wants to merge 6 commits into
lpiwowar wants to merge 6 commits into
Conversation
Align dependencies with openstack-k8s-operators namespace to enable consumption of the OpenStackControlPlane CRD structure. This requires downgrading controller-runtime to 0.19.7, which cascades to other dependency updates. Future work should consider adopting the renovate repository [1] from openstack-k8s-operators for managing downgrade exceptions and replace directives exceptions [2]. [1] https://github.com/openstack-k8s-operators/renovate-config [2] https://github.com/openstack-k8s-operators/openstack-operator/blob/ace3aed5d215767cadadfd0c594df996e6efe889/go.mod#L155
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lpiwowar The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Introduce logic for watching CRDs that may be created after the operator starts but are not expected to exist before installation (e.g., OpenStackControlPlane). This provides a foundation for dynamically watching such CRDs and can be extended to support additional resources. If any dynamically watched CRD is not present in the cluster, reconciliation is requeued every 30 seconds. Once all dynamically watched CRDs are detected, the forced requeue stops. Known limitation: Once a CRD is registered with the controller, it cannot be unregistered. If the CRD is later removed from the cluster, the following error appears in logs: failed to list core.openstack.org/v1beta1, Kind=OpenStackControlPlane: the server could not find the requested resource A potential solution is to restart the controller via os.Exit(0) when CRD removal is detected, but this causes downtime. For now, we accept this log message as a trade-off.
Add infrastructure to watch OpenStackControlPlane CRD after it becomes available in the cluster during OpenStack installation. This enables the operator to start monitoring OpenStackControlPlane resources once the CRD is installed, rather than requiring it to exist at operator startup.
Implement ReconcileMCPServer() to deploy the OpenStack Lightspeed MCP Server when an OpenStackControlPlane instance is present. Before deployment, copy required resources to the namespace where the OpenStackLightspeed instance is created: - ConfigMap containing clouds.yaml - Secret containing secrets.yaml - Secret containing the CA bundle Each copied resource includes an openstack.org/checksum annotation with a checksum of its data. This checksum is passed to the deployment to ensure it restarts when secrets are updated.
Include OpenStackLightspeedMCPServerReady status condition in test assertions to validate MCP server deployment status.
Add two KUTTL tests for MCP server deployment: - mcp-server-present-openstack-deployment: Installs OpenStack Lightspeed and verifies MCP server deployment when an OpenStackControlPlane instance is present, then confirms the MCP server is removed when the OpenStackControlPlane is deleted. - update-mcp-server-present-openstack-deployment: Validates that the MCP server restarts and accesses updated resources (clouds.yaml, secure.yaml, combined-ca-bundle) when any required resource is modified. Both tests mock OpenStack deployment by installing the OpenStackControlPlane CRD and manually creating the OpenStackControlPlane instance. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
lpiwowar
force-pushed
the
lpiwowar/OSPRH-25524-MCP
branch
from
70b0765 to
26de235
Compare
|
PR needs rebase. DetailsInstructions 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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Warning
This PR servers only as a PREVIEW. It is not meant to be merged as stated in the reasons below. You can test this PR by running the operator locally with
make runbut it won't work when the operator is installed from the bundle.This PR introduces logic for deploying the MCP server when an OpenStack deployment is detected (i.e., when
OpenStackControlPlaneis created). As of now, a rough outline of the PR is as follows:OpenStackControlPlaneis present.openstacknamespace into theopenshift-lightspeednamespace, where OpenStack Lightspeed and OpenShift Lightspeed related resources currently reside.This has one shortcoming that prevents this PR from being merged in its current state: OpenShift Lightspeed Operator does not support multi-namespace deployment. This means that if we deploy our operator in a namespace configured with an
OperatorGroupthat targets both theopenshift-lightspeednamespace and theopenstacknamespace, OLM won't deploy the OLS operator because of the lack of support on the OLS side.Potential Solution
#1openstack-operatorsnamespace alongside the other OpenStack operators.openstacknamespace (this nicely follows the OpenStack pattern as well).openshift-lightspeednamespace with theOperatorGroupconfigured to target only that namespace.In the long run, this is a good solution, in my opinion, since it follows the OpenStack pattern, and once we move to Lightspeed core, we simply cut off the
openshift-lightspeednamespace with the OLS operator. This requires two changes:One additional PR before this one that ensures our operator follows this pattern: it gets installed in the
openstack-operatorsnamespace by default, deploys the OLS operator in theopenshift-lightspeednamespace, and includes updates to kuttl tests.Modify this PR: drop the copying of the resources from the
openstacknamespace to theopenshift-lightspeednamespace (a nice simplification as well).Potential Solution
#2( by @umago )Put this PR on hold and wait until the Lightspeed Core migration is completed. Then we can reuse this PR almost as-is with minor tweaks. We would continue to run in a separate namespace renamed from
openshift-lightspeedtoopenstack-lightspeed.Update: A decision has been made. We will go with the solution
#2. This means this PR is on hold until we migrate to Lightspeed Core (i.e., until the installation of the OLS operator is part of our operator's code).