Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 17 additions & 17 deletions site/developer.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,18 +6,18 @@ This page provides information for developers who wish to understand or contribu

The following software are required to obtain and build the operator:

* git (1.8 or later recommended)
* Git (1.8 or later recommended)
* Apache Maven (3.3 or later recommended)
* Java Developer Kit (1.8u131 or later recommended, not 1.9)
* Docker 17.03.1.ce

The operator is written primarily in Java and BASH shell scripts. The Java code uses features introduced in Java 1.8, for example closures, but does not use any Java 1.9 feature.

Since the target runtime environment for operator is Oracle Linux, no particular effort has been made to ensure the build or tests run on any other operating system. Please be aware that Oracle will not provide support for, or accept pull requests to add support for other operating systems.
Because the target runtime environment for the operator is Oracle Linux, no particular effort has been made to ensure the build or tests run on any other operating system. Please be aware that Oracle will not provide support, or accept pull requests to add support, for other operating systems.

## Obtaining the operator source code

The operator source code is published on GitHub at https://github.com/oracle/weblogic-operator. Developers may clone this repository to a local machine, or if desired create a fork in their personal namespace and clone the fork. Developers who are planning to submit a pull request are advised to create a fork.
The operator source code is published on GitHub at https://github.com/oracle/weblogic-operator. Developers may clone this repository to a local machine or, if desired, create a fork in their personal namespace and clone the fork. Developers who are planning to submit a pull request are advised to create a fork.

To clone the repository from GitHub, issue this command:

Expand All @@ -29,13 +29,13 @@ git clone https://github.com/oracle/weblogic-operator

The operator is built using [Apache Maven](http://maven.apache.org). The build machine will also need to have Docker installed.

To build the operator issue the following command in the project directory:
To build the operator, issue the following command in the project directory:

```
mvn clean install
```

This will compile the source files, build JAR files containing the compiled classes and libraries needed to run the Operator and will also execute all of the unit tests.
This will compile the source files, build JAR files containing the compiled classes and libraries needed to run the operator, and will also execute all of the unit tests.

## Building Javadoc

Expand All @@ -49,9 +49,9 @@ The Javadoc is also available in the GitHub repository at [https://oracle.github

## Running integration tests

The project includes integration tests that can be run against a Kubernetes *cluster*. If you want to use these tests, you will need to provide your own Kubernetes *cluster*. You will need to obtain the kube.config file for an admin user and make it available on the machine running the build. Tests will run against Kubernetes 1.7.x and 1.8.x currently. There are some issues with 1.9, which are being worked on.
The project includes integration tests that can be run against a Kubernetes *cluster*. If you want to use these tests, you will need to provide your own Kubernetes *cluster*. You will need to obtain the `kube.config` file for an administrator user and make it available on the machine running the build. Tests will run against Kubernetes 1.7.x and 1.8.x currently. There are some issues with 1.9, which are being worked on.

To run the tests, uncomment the following `execution` in the `pom.xml` and update the `KUBECONFIG` to point to your kube config file.
To run the tests, uncomment the following `execution` element in the `pom.xml` file and update the `KUBECONFIG` to point to your kube config file.

```
<!--
Expand Down Expand Up @@ -79,35 +79,35 @@ These test assume that the RBAC definitions exist on the Kubernetes *cluster*.
./create-weblogic-operator.sh -g -i create-operator-inputs.yaml
```

This will create a file called `rbac.yaml` which you will need to apply to your cluster:
This will create a file called `rbac.yaml`, which you will need to apply to your cluster:

```
kubectl apply -f rbac.yaml
```

Once this is done, and the `execution` is uncommented, the tests will run against your cluster.
After this is done, and the `execution` is uncommented, the tests will run against your cluster.

## Running the operator from an IDE

The operator can be run from an IDE, which is useful for debugging. In order to do so, the machine running the IDE must be configured with a Kubernetes configuration file in `~/.kube/config` or in a location pointed to by the `KUBECONFIG` environment variable.

Configure the IDE to run the class `oracle.kubernetes.operator.Main`.

You may need to create a directory called `/operator` on your machine. Please be aware that the *operator* code is targeted to Linux, and while it will run fine on macOS, it will probably not run on other operating systems. If you develop on another operating system, you should deploy the operator to a Kubernetes *cluster* and use remote debugging instead.
You may need to create a directory called `/operator` on your machine. Please be aware that the *operator* code is targeted to Linux, and although it will run fine on macOS, it will probably not run on other operating systems. If you develop on another operating system, you should deploy the operator to a Kubernetes *cluster* and use remote debugging instead.

## Running the operator in a Kubernetes cluster

To run the *operator* in a Kubernetes *cluster* you need to build the Docker image and then deploy it to your *cluster*.
To run the *operator* in a Kubernetes *cluster*, you need to build the Docker image and then deploy it to your *cluster*.

After you have run the build (i.e. `mvn clean install`), create the Docker image as follows:
After you have run the build (that is, `mvn clean install`), create the Docker image as follows:

```
docker build -t weblogic-kubernetes-operator:markxnelson --no-cache=true .
```

We recommend that you use a tag other than `latest` to make it easy to tell your image apart from the "real" one. In the example above, we just put in the github ID of the developer.
We recommend that you use a tag other than `latest` to make it easy to distinguish your image from the "real" one. In the example above, we just put in the GitHub ID of the developer.

Next upload your image to your Kubernetes server as follows:
Next, upload your image to your Kubernetes server as follows:

```
# on your build machine
Expand All @@ -117,7 +117,7 @@ scp operator.tar YOUR_USER@YOUR_SERVER:/some/path/operator.tar
docker load < /some/path/operator.tar
```

Verify you have the right image by running `docker images | grep webloogic-kubernetes-operator` on both machines and comparing the image ID.
Verify that you have the right image by running `docker images | grep webloogic-kubernetes-operator` on both machines and comparing the image ID.

To create the Kuberentes YAML file to deploy the *operator*, update the inputs file (`create-operator-inputs.yaml`) and make sure the `imagePullPolicy` is set to `Never` and the `image` matches the name you used in your `docker build` command. Then run the *operator* installation script to deploy the *operator*:

Expand All @@ -135,8 +135,8 @@ Write me
This project has adopted the following coding standards:

* All indents are two spaces.
* Javadoc must be provided for all public packages, classes and methods and must include all parameters and returns.
* All non-trivial methods should include `LOGGER.entering()` and `LOGGER.exiting()` calls.
* Javadoc must be provided for all public packages, classes, and methods and must include all parameters and returns.
* All nontrivial methods should include `LOGGER.entering()` and `LOGGER.exiting()` calls.
* The `LOGGER.exiting()` call should include the value that is going to be returned from the method, unless that value includes a credential or other sensitive information.
* Before throwing an exception, there should be a call to `LOGGER.throwing(e)` to log the exception.
* write me
Expand Down