Skip to content

[OSPRH-21185] Install OLS operator#27

Merged
openshift-merge-bot[bot] merged 10 commits into
openstack-lightspeed:mainfrom
lpiwowar:lpiwowar/OSPRH-21185
Nov 18, 2025
Merged

[OSPRH-21185] Install OLS operator#27
openshift-merge-bot[bot] merged 10 commits into
openstack-lightspeed:mainfrom
lpiwowar:lpiwowar/OSPRH-21185

Conversation

@lpiwowar

@lpiwowar lpiwowar commented Nov 5, 2025

Copy link
Copy Markdown
Contributor

Implement automatic installation, version checking, and lifecycle management of the OpenShift Lightspeed operator. Add support for both user-installed and instance-owned installation modes, with proper ownership tracking.

If the OLS operator has already been installed, then the OpenStack lightspeed operator checks it version. If the version is valid OpenStack Lightspeed utilizes the preinstalled OLS operator.

If the OLS operator has not been already installed, then the operator installs it. In this mode, when the OpenStackLightspeed instance is created, the OLS operator is automatically uninstalled as well. Whereas in the preinstalled OLS operator mode, the OLS operator stays even after the removal of the OpenStackLightspeed instance.

@lpiwowar lpiwowar force-pushed the lpiwowar/OSPRH-21185 branch from 86dc3ce to ee1e2b8 Compare November 5, 2025 18:24
Comment thread config/crd/bases/lightspeed.openstack.org_openstacklightspeeds.yaml Outdated
@lpiwowar lpiwowar force-pushed the lpiwowar/OSPRH-21185 branch 2 times, most recently from f9dbd37 to 8b47be5 Compare November 13, 2025 11:37
Implement automatic installation, version checking ,and lifecycle
management of the OpenShift Lightspeed operator. Add support for both
user-installed and instance-owned installation modes with proper
ownership tracking.

If the OLS operator has already been installed then the OpenStack
Lightspeed operator checks it version. If the version is valied
OpenStack Lightspeed utilizes the preinstalled OLS operator.

If the OLS operator has not been already installed then the operator
installs it. In this mode when the OpenStackLightspeed instance is
created the OLS operator is automatically uninstalled as well. Whereas
in the preinstalled OLS operator mode the OLS oeprator stays even after
the removal of the OpenStackLightspeed instance.
Introduce a ping function that adds a random label to OLSConfig
resources to trigger reconciliation by the OpenShift Lightspeed
operator. This ensures the operator updates the Status field when
the OLSConfig is not ready.

This addresses a current limitation where the OLS operator does
not automatically update the OLSConfig status when installed in
the openstack-lightspeed namespace.
Because the OpenStack Lightspeed operator now depends on the
OPENSHIFT_LIGTSPEED_OPERATOR_VERSION variable we have to ensure that it
is set when we run the operator during development with make run.
@lpiwowar lpiwowar force-pushed the lpiwowar/OSPRH-21185 branch from 8b47be5 to 4405e51 Compare November 14, 2025 17:16
@openshift-ci

openshift-ci Bot commented Nov 14, 2025

Copy link
Copy Markdown

[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

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

Update README to remove manual OLS operator deployment step since the
operator now handles this automatically. This commit also renames the
catalog-deploy to openstack-lightspeed-deploy to better reflect its
behavior.
Update go.mod and go.sum with latest dependency versions.
Split RBAC permissions into cluster-scoped (read-only CSV list/watch)
and namespace-scoped (CSV/subscription/installplan management) roles to
support namespace-scoped operator deployment.

Note that this commit adjusts the permissions that are related to the
recent changes (OLS operator installation). In the follow up changes we
have to modify the permissions for other resources as well.
Configure the operator to watch only the namespace specified in the
WATCH_NAMESPACE environment variable instead of watching all
namespaces cluster-wide.

This enables namespace-scoped RBAC permissions for the operator.

GetOLSOperatorCSV now uses a raw client to query CSVs cluster-wide,
since the default controller client is scoped to WATCH_NAMESPACE.
@lpiwowar lpiwowar force-pushed the lpiwowar/OSPRH-21185 branch from 4405e51 to adba0a0 Compare November 14, 2025 17:25
@lpiwowar

Copy link
Copy Markdown
Contributor Author

/hold

We have to first figure out how we want to depend on the OLS Operator. If we decide that we still want to use the OLS operator to deploy OpenStack Lightspeed than we have to ensure that OLS team does not delete old versions of their operator from the OperatorHub.

@lpiwowar lpiwowar marked this pull request as ready for review November 14, 2025 17:27
@openshift-ci openshift-ci Bot requested review from Akrog and umago November 14, 2025 17:27

@umago umago left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM in general, left two ideas inline. Let me know what u think

Comment thread scripts/env.sh
Comment thread internal/controller/ols_install.go Outdated
@lpiwowar

Copy link
Copy Markdown
Contributor Author

@umago: I made the changes you wanted me to do. Let me know what you think:). For now, I kept the workaround in the PR [1]. The thing is that the Status section update for the OLSConfig seems to be a tiny bit flaky in nature. I thought it was caused by the us not installing the OpenShift Lightspeed operator in the correct namespace, but sometimes it does not work even when we install the OLS operator into the correct namespace. I opened a bug for this on the side of OLS operator. But regardless of this, I think it is not preventing us from merging it.

[1] https://github.com/openstack-lightspeed/operator/pull/27/files

@lpiwowar

Copy link
Copy Markdown
Contributor Author

/unhold

I'm removing the hold label because we agreed that:

  • for now we are going to install always the latest version (until we figure out with the OLS team how they can keep the old versions in the Operator Hub)
  • we move the installation to the openshift-lightspeed namespace (this should prevent from facing any potential issues related to installing the operator to unsupported namespace)

@umago umago left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few nits, other than that LGTM!

Comment thread internal/controller/ols_install.go Outdated
Comment thread config/manifests/bases/openstack-lightspeed-operator.clusterserviceversion.yaml Outdated
Default OPENSHIFT_LIGHTSPEED_OPERATOR_VERSION to "latest" to ensure
compatibility with Operator Hub, which does not retain older versions
indefinitely.

Changes:
- Set default version to "latest" in manager.yaml
- Update GetRecommendedOLSVersion to handle "latest" value
- Add SetStartingCSV helper to set version conditionally in
  Subscriptions
- Return error when user-installed OLS operator is detected
  instead of attempting version compatibility check

Future work should consider pinning to specific versions
for production stability.
Install the OpenStack Lightspeed operator into the openshift-lightspeed
namespace by default to align with ownership responsibilities and ensure
compatibility, as the OLS operator is not guaranteed to function correctly
in other namespaces.
@lpiwowar lpiwowar force-pushed the lpiwowar/OSPRH-21185 branch from b1bc750 to 1c63181 Compare November 18, 2025 16:47
@umago

umago commented Nov 18, 2025

Copy link
Copy Markdown
Contributor

/lgtm

@openshift-ci openshift-ci Bot added the lgtm label Nov 18, 2025
@openshift-merge-bot openshift-merge-bot Bot merged commit 0e1d583 into openstack-lightspeed:main Nov 18, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants