Skip to content

Latest commit

 

History

History
182 lines (131 loc) · 7.14 KB

CONTRIBUTING.adoc

File metadata and controls

182 lines (131 loc) · 7.14 KB
Raw

How to Contribute to the Jaeger Operator for Kubernetes

Table of Contents

We’d love your help!

This project is Apache 2.0 licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted.

We gratefully welcome improvements to documentation as well as to code.

Certificate of Origin

By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the [DCO](DCO) file for details.

Getting Started

This project is a regular Kubernetes Operator built using the Operator SDK. Refer to the Operator SDK documentation to understand the basic architecture of this operator.

Installing the Operator SDK command line tool

At the time of this writing, the Operator SDK GitHub page listed the following commands as required to install the command line tool:

mkdir -p $GOPATH/src/github.com/operator-framework
cd $GOPATH/src/github.com/operator-framework
git clone https://github.com/operator-framework/operator-sdk
cd operator-sdk
git checkout v0.1.1
make dep
make install

Alternatively, a released binary can be used instead:

curl https://github.com/operator-framework/operator-sdk/releases/download/v0.1.1/operator-sdk-v0.1.1-x86_64-linux-gnu -sLo $GOPATH/bin/operator-sdk
chmod +x $GOPATH/bin/operator-sdk
Note
 Make sure your $GOPATH/bin is part of your regular $PATH.

Developing

As usual for operators following the Operator SDK, the dependencies are checked into the source repository under the vendor directory. The dependencies are managed using go dep. Refer to that project’s documentation for instructions on how to add or update dependencies.

The first step is to get a local Kubernetes instance up and running. The recommended approach is using minikube. Refer to the Kubernetes' documentation for instructions on how to install it.

Once minikube is installed, it can be started with:

minikube start
Note
 Make sure to read the documentation to learn the performance switches that can be applied to your platform.

Once minikube has finished starting, get the Operator running:

make run

At this point, a Jaeger instance can be installed:

kubectl apply -f deploy/examples/simplest.yaml
kubectl get jaegers
kubectl get pods

To remove the instance:

kubectl delete -f deploy/examples/simplest.yaml

Tests should be simple unit tests and/or end-to-end tests. For small changes, unit tests should be sufficient, but every new feature should be accompanied with end-to-end tests as well. Tests can be executed with:

make test
Note
 you can adjust the Docker image namespace by overriding the variable NAMESPACE, like: make test NAMESPACE=quay.io/my-username. The full Docker image name can be customized by overriding BUILD_IMAGE instead, like: make test BUILD_IMAGE=quay.io/my-username/jaeger-operator:0.0.1

Similar instructions also work for OpenShift, but the target run-openshift can be used instead of run.

Model changes

The Operator SDK generates the pkg/apis/io/v1alpha1/zz_generated.deepcopy.go file via the command make generate. This should be executed whenever there’s a model change (pkg/apis/io/v1alpha1/types.go)

Ingress configuration

Kubernetes comes with no ingress provider by default. For development purposes, when running minikube, the following command can be executed to install an ingress provider:

make ingress

This will install the NGINX ingress provider. It’s recommended to wait for the ingress pods to be in the READY and RUNNING state before starting the operator. You can check it by running:

kubectl get pods -n ingress-nginx

To verify that it’s working, deploy the simplest.yaml and check the ingress routes:

$ kubectl apply -f deploy/examples/simplest.yaml
jaeger.io.jaegertracing/simplest created
$ kubectl get ingress
NAME             HOSTS     ADDRESS          PORTS     AGE
simplest-query   *         192.168.122.69   80        12s

Accessing the provided "address" in your web browser should display the Jaeger UI.

Storage configuration

There are a set of templates under the test directory that can be used to setup an Elasticsearch and/or Cassandra cluster. Alternatively, the following commands can be executed to install it:

make es
make cassandra

Operator-Lifecycle-Manager Integration

The Operator-Lifecycle-Manager (OLM) can install, manage, and upgrade operators and their dependencies in a cluster.

With OLM, users can:

  • Define applications as a single Kubernetes resource that encapsulates requirements and metadata

  • Install applications automatically with dependency resolution or manually with nothing but kubectl

  • Upgrade applications automatically with different approval policies

OLM also enforces some constraints on the components it manages in order to ensure a good user experience.

The Jaeger community provides and mantains a ClusterServiceVersion (CSV) YAML to integrate with OLM.

With the latest master branch of the operator-sdk one can generate and update CSVs based on the yaml files in the deploy folder. The Jaeger CSV can be updated to version 1.9.0 with the following command:

$ operator-sdk olm-catalog gen-csv --csv-version 1.9.0
INFO[0000] Generating CSV manifest version 1.9.0
INFO[0000] Create deploy/olm-catalog/jaeger-operator.csv.yaml
INFO[0000] Create deploy/olm-catalog/_generated.concat_crd.yaml

The CSV YAML can then be tested with this command:

$ operator-sdk scorecard --cr-manifest deploy/examples/simplest.yaml --csv-path deploy/olm-catalog/jaeger-operator.csv.yaml --init-timeout 30
Checking for existence of spec and status blocks in CR
Checking that operator actions are reflected in status
Checking that writing into CRs has an effect
Checking for CRD resources
Checking for existence of example CRs
Checking spec descriptors
Checking status descriptors
Basic Operator:
	Spec Block Exists: 1/1 points
	Status Block Exist: 1/1 points
	Operator actions are reflected in status: 0/1 points
	Writing into CRs has an effect: 1/1 points
OLM Integration:
	Owned CRDs have resources listed: 0/1 points
	CRs have at least 1 example: 1/1 points
	Spec fields with descriptors: 0/12 points
	Status fields with descriptors: N/A (depends on an earlier test that failed)

Total Score: 4/18 points