crate
Crate Operator on OpenShift
Hello! I am trying to use the Crate Operator on an OpenShift instance, similarly to https://github.com/crate/crate-operator/issues/300, I had trouble with explicit permissions on finalizers. This was easiliy solved by updating the rbac. However, this still does not allow the operator to work. When creating a new instance through a custom resource, the operator logs the following message:
[2025-03-11 11:42:49,258] kopf.objects [INFO ] [krateo-system/finops-finops-cratedb-custom-resource] Trying to create system user ...
[2025-03-11 11:42:49,271] kopf.objects [ERROR ] [krateo-system/finops-finops-cratedb-custom-resource] ... failed. Status: 404 Message: Invalid response status
This seems to be caused by this call in the bootstrap: https://github.com/crate/crate-operator/blob/ae24778f403618d7dfce30fa7874d4b43d548fe1/crate/operator/bootstrap.py#L129 which in turn calls this Kubernetes library: https://github.com/crate/crate-operator/blob/ae24778f403618d7dfce30fa7874d4b43d548fe1/crate/operator/bootstrap.py#L113
In the readme of https://github.com/RedHatQE/openshift-python-wrapper/, it explicitly states:
The wrapper also provides additional capabilities, such as resource-specific functionality that otherwise needs to be implemented by users.
[...]
One example of simplified usage is interacting with a container.
Running a command inside a container requires using Kubernetes stream, handling errors, and more.
The wrapper handles it all and provides simple and intuitive functionality.
which makes me assume that this is the root cause of this issue: OpenShift uses a different API to manage some objects, requiring different handling.
I assume that a traditional deployment of CrateDB will work just fine on OpenShift (which is going to be what I will do now), however, this completely stops the operator from working in these types of clusters.
Hi @FrancescoL96
Thank you for bringing this up.
Currently, we don’t test or officially support OpenShift. There are no immediate plans to change this unless we see significant commercial demand. However, we’re always open to suggestions or pull requests to improve our open-source components.
I’ll keep this open to track any further interest in OpenShift support or related issues.
As a followup, we made some further analysis, and found that the library used for the Kubernetes API kubernetes_asyncio is a modified version of the standard Kubernetes Python Library, which has been planned for a merge for quite some time, but has not happend yet.
To add OpenShift support to the Crate Operator, the kubernetes_asyncio would need to integrate the OpenShift wrapper, which is not planned at all by the original maintainers.
Since this issue is extremely complex and we needed a solution, we created a configurable Helm chart which is open to use for everyone in the same situation, it has been tested on AKS and OpenShift (and Kind): https://github.com/krateoplatformops/cratedb-chart
The template install an instance of CrateDB and automatically creates the permissions for OpenShift and the system user inside the database, along a secret in the same namespace that contains the password.