For [various reasons](https://okd-internal.docs.cern.ch/design/cern-cloud-cluster-deployment/), we deploy our OpenShift clusters with infrastructure platform type set to 'None' instead of 'OpenStack'.
However, we still want some behaviors that come when setting the platform type to 'OpenStack', e.g. the automatic deployment of [machine-api-controllers](https://gitlab.cern.ch/paas-tools/okd4-deployment/machine-api-operator).
Thus, this repository contains patches that map the 'None' platform type to 'OpenStack' for our use-cases.
The Gitlab repository is configured to automatically mirror the [upstream machine-api-operator repository](https://github.com/openshift/machine-api-operator).
Use the following workflow to port our custom patches to a new release:
```sh
# Make sure your repo is up-to-date
git fetch origin
# Check out the pristine upstream release
git checkout origin/release-4.x
# Push a new branch with the pristine upstream release
git checkout -b cern-4.x
git push origin cern-4.x
# Create a new branch for development
git checkout -b cern-4.x-dev
```
Then, locate the latest patches that have been made by us.
This can be done by checking out an old release branch (e.g. `cern-4.8`) and looking at the commits prefixed with `[cern]`.
```
git log origin/cern-4.8
git cherry-pick [CERN_PATCH_REFS]
```
At this point, you might need to resolve the merge conflicts (*fingers crossed*).
Afterwards, commit your changes with a `[cern]` prefix and push them to the dev branch.
Finally, create a merge request from `cern-4.x-dev` to `cern-4.x` so someone else can review your changes.
# Machine API Operator
The Machine API Operator manages the lifecycle of specific purpose CRDs, controllers and RBAC objects that extend the Kubernetes API.
