The Cluster Cloud Controller Manager operator (CCCMO) manages and updates the various Cloud Controller Managers deployed on top of OpenShift. The operator is based on the Kubebuilder framework and controller-runtime libraries. It is installed via Cluster Version Operator (CVO).
Kubernetes is in the process of migrating its cloud controller functionality out of the Kubernetes core and into separate Cloud Controller Managers (see KEP 2395 for more information). As this process is an on-going effort, we will document the status and progress of this operator, as well as the supported platforms, until the operator has gone into general availability (GA) in OpenShift.
Alpha
The operator is being actively developed, with features and testing being added on a regular basis. It is currently available for experimentation and testing but should not be used for production.
| Platform | Included in Operator | Tested in CI |
|---|---|---|
| AWS | Yes | Yes |
| Azure | Yes | Yes |
| GCP | Yes | Yes |
| OpenStack | Yes | Yes |
| vSphere | No | |
| IBM | Yes | |
| Alibaba | No | |
| Power VS | Yes |
The CCCMO deploys controllers which provide a central core component of Kubernetes. As such, its deployment and operation is highly sensitive to cluster bootstrapping and initial payload deployment. In general, it is best to allow the OpenShift installer to manage its operation.
To better understand how this operator is deployed, please see the manifests directory. It contains a series of Kubernetes YAML manifests which are deployed by the CVO during installation. Additionally, this OpenShift enhancement(currently in review) provides detailed information about how the operator will be deployed, operated, and upgraded.
More detailed guide is in #hacking-guide
Prerequisites
- Go language 1.16+
- GNU Make
All development related tasks can be run through the Makefile. Supplemental scripts can be found in the hack directory.
If you do not have the necessary tools for building, but do have access to Podman or Docker, you may use the hack/container-run.sh script to run Makefile targets in a container. See the container-run.sh file for usage instructions.
To build the operator binary, and run related linting tests, type make or make build from the root of the project.
This step is extensively covered in Integrating a new cloud provider in Cluster-cloud-controller-manager-operator (CCCMO)
After adding or updating dependencies in the go.mod file, run make vendor to ensure that all new dependencies are added to the vendor directory. It is also useful to run make vet to ensure that no build-time errors have been introduced during the vendor process.
The CCCMO has multiple levels of testing: unit tests, and end to end (e2e) functionality tests. As a developer you should run the unit tests locally to ensure that your changes do not break the tests. Although running the e2e tests manually can be a rewarding experience, it is also complicated to configure and maintain. For these reasons it is often better to let the continuous integration systems run the e2e tests automatically for you on pull requests.
To invoke the unit tests, run make unit. If you wish to also run the code generation and verification steps, run make test.
The CCCMO e2e tests are configured and deployed from the OpenShift Release repository. You will find the CCCMO specific configurations in the release/ci-operator/config/openshift/cluster-cloud-controller-manager-operator directory. For more information about these tests and how they are run and configured, please see the OpenShift CI Docs.