verrazzano-operator

Verrazzano Operator

The Verrazzano Operator is the Kubernetes operator that runs in the Verrazzano Management Cluster, watches local custom resource definitions for models/bindings, and launches micro operators into Verrazzano Managed Clusters.

Project Status

Current functionality:

• Learns about Managed Clusters through a VerrazzanoManagedCluster custom resource, and then creates Kubernetes clients and watchers for those clusters.

• Watches the local Kubernetes cluster in the default namespace for VerrazzanoModel and VerrazzanoBinding custom resources.

• A VerrazzanoModel/VerrazzanoBinding pair describes a Verrazzano application and defines which application components should be installed on which VerrazzanoManagedCluster.

• On creation or update of a VerrazzanoModel/VerrazzanoBinding pair, the Verrazzano Operator launches:

  • A Verrazzano Monitoring instance.
  • Custom resources needed to deploy application components.
  • Agents forwarding logs and metrics to the Verrazzano Monitoring Instance.

• On deletion of a VerrazzanoBinding, deletes all related resources deployed.

• On updates to the Managed Cluster's objects (deployments, micro operator custom resources) created by the Verrazzano Operator, triggers a reprocessing of the owning VerrazzanoBinding. This causes any drift in expecting state to immediately be fixed by the Verrazzano Operator.

Artifacts

On a successful release (which occurs on a Git tag), this repo publishes a Docker image: container-registry.oracle.com/verrazzano/verrazzano-operator:tag

Building

To build the operator:

• Go build:

  make go-install
  

• Docker build:

  export ACCESS_USERNAME=<username with read access to github verrazzano project>
  export ACCESS_PASSWORD=<password for account with read access to github verrazzano project>
  make build
  

Updating Custom Resource Definitions

The custom resource definitions used by the Verrazzano Operator are auto generated by the Verrazzano project verrazzano-crd-generator. The steps to include changes made to the custom resource definitions are:

• Make the API changes in the verrazzano-crd-generator project
• Tag a branch of verrazzano-crd-generator, for example 0.n
• Edit go.mod to use the newly tagged API changes. For example github.com/verrazzano/verrazzano-crd-generator v1.2.0
• Run the make target:

  make go-install
  

Running

Create the custom resource definitions in the cluster where you wish to run the Verrazzano Operator. This is a one-time operation:

kubectl create -f vendor/github.com/verrazzano/verrazzano-crd-generator/deploy/crds/verrazzano.io_verrazzanomanagedclusters_crd.yaml
kubectl create -f vendor/github.com/verrazzano/verrazzano-crd-generator/deploy/crds/verrazzano.io_verrazzanobindings_crd.yaml
kubectl create -f vendor/github.com/verrazzano/verrazzano-crd-generator/deploy/crds/verrazzano.io_verrazzanomodels_crd.yaml

Development

Running Locally

While developing, it's usually most efficient to run the Verrazzano Operator as an out-of-cluster process, pointing it to your Kubernetes cluster:

export KUBECONFIG=<your_kubeconfig>
make go-run

Running Tests

To run unit tests:

make unit-test

Contributing to Verrazzano

Oracle welcomes contributions to this project from anyone. Contributions may be reporting an issue with the operator or submitting a pull request. Before embarking on significant development that may result in a large pull request, it is recommended that you create an issue and discuss the proposed changes with the existing developers first.

If you want to submit a pull request to fix a bug or enhance an existing feature, please first open an issue and link to that issue when you submit your pull request.

If you have any questions about a possible submission, feel free to open an issue too.

Contributing to the Verrazzano Operator repository

Pull requests can be made under The Oracle Contributor Agreement (OCA), which is available at https://www.oracle.com/technetwork/community/oca-486395.html.

For pull requests to be accepted, the bottom of the commit message must have the following line, using the contributor’s name and e-mail address as it appears in the OCA Signatories list.

Signed-off-by: Your Name <you@example.org>

This can be automatically added to pull requests by committing with:

git commit --signoff

Only pull requests from committers that can be verified as having signed the OCA can be accepted.

Pull request process

• Fork the repository.
• Create a branch in your fork to implement the changes. We recommend using the issue number as part of your branch name, for example, 1234-fixes.
• Ensure that any documentation is updated with the changes that are required by your fix.
• Ensure that any samples are updated if the base image has been changed.
• Submit the pull request. Do not leave the pull request blank. Explain exactly what your changes are meant to do and provide simple steps on how to validate your changes. Ensure that you reference the issue you created as well. We will assign the pull request to 2-3 people for review before it is merged.

Introducing a new dependency

Please be aware that pull requests that seek to introduce a new dependency will be subject to additional review. In general, contributors should avoid dependencies with incompatible licenses, and should try to use recent versions of dependencies. Standard security vulnerability checklists will be consulted before accepting a new dependency. Dependencies on closed-source code, including WebLogic Server, will most likely be rejected.