public_git
/
postgres-operator
mirror of https://github.com/zalando/postgres-operator.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update CRD configuration docs and fix the CDP build

This commit is contained in:
Sergey Dudoladov 2018-11-13 11:55:27 +01:00
parent f25351c36a
commit 409d4875b1
2 changed files with 20 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
delivery.yaml
View File

@ -22,7 +22,7 @@ pipeline:
go version go version
- desc: 'Install Docker' - desc: 'Install Docker'
cmd: | cmd: |
curl -sSL https://get.docker.com/ | sh curl -fLOsS https://delivery.cloud.zalando.com/utils/ensure-docker && sh ensure-docker && rm ensure-docker
- desc: 'Symlink sources into the GOPATH' - desc: 'Symlink sources into the GOPATH'
cmd: | cmd: |
mkdir -p $OPERATOR_TOP_DIR mkdir -p $OPERATOR_TOP_DIR

31
docs/reference/operator_parameters.md
View File

@ -10,29 +10,37 @@ configuration.
configuration structure. There is an configuration structure. There is an
[example](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/configmap.yaml) [example](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/configmap.yaml)
* CRD-based configuration. The configuration is stored in the custom YAML * CRD-based configuration. The configuration is stored in a custom YAML
manifest, an instance of the custom resource definition (CRD) called manifest. The manifest is an instance of the custom resource definition (CRD) called
`OperatorConfiguration`. This CRD is registered by the operator `OperatorConfiguration`. The operator registers this CRD
during the start when `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` variable is during the start and uses it for configuration if the [operator deployment manifest ](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgres-operator.yaml#L21) sets the `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` env variable to a non-empty value. The variable should point to the
set to a non-empty value. The CRD-based configuration is a regular YAML `postgresql-operator-configuration` object in the operator's namespace.
document; non-scalar keys are simply represented in the usual YAML way. The
usage of the CRD-based configuration is triggered by setting the The CRD-based configuration is a regular YAML
`POSTGRES_OPERATOR_CONFIGURATION_OBJECT` variable, which should point to the document; non-scalar keys are simply represented in the usual YAML way.
`postgresql-operator-configuration` object name in the operators namespace.
There are no default values built-in in the operator, each parameter that is There are no default values built-in in the operator, each parameter that is
not supplied in the configuration receives an empty value. In order to not supplied in the configuration receives an empty value. In order to
create your own configuration just copy the [default create your own configuration just copy the [default
one](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml) one](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
and change it. and change it.
CRD-based configuration is more natural and powerful then the one based on To test the CRD-based configuration locally, use the following
```bash
kubectl create -f manifests/operator-service-account-rbac.yaml
kubectl create -f manifests/postgres-operator.yaml # set the env var as mentioned above
kubectl create -f manifests/postgresql-operator-default-configuration.yaml
kubectl create -f operatorconfigurations postgresql-operator-default-configuration -o yaml
```
Note that the operator first registers the definition of the CRD `OperatorConfiguration` and then waits for an instance of the CRD to be created. In between these two event the operator pod may be failing since it cannot fetch the not-yet-existing `OperatorConfiguration` instance.
The CRD-based configuration is more powerful than the one based on
ConfigMaps and should be used unless there is a compatibility requirement to ConfigMaps and should be used unless there is a compatibility requirement to
use an already existing configuration. Even in that case, it should be rather use an already existing configuration. Even in that case, it should be rather
straightforward to convert the configmap based configuration into the CRD-based straightforward to convert the configmap based configuration into the CRD-based
one and restart the operator. The ConfigMaps-based configuration will be one and restart the operator. The ConfigMaps-based configuration will be
deprecated and subsequently removed in future releases. deprecated and subsequently removed in future releases.
Note that for the CRD-based configuration configuration groups below correspond Note that for the CRD-based configuration groups of configuration options below correspond
to the non-leaf keys in the target YAML (i.e. for the Kubernetes resources the to the non-leaf keys in the target YAML (i.e. for the Kubernetes resources the
key is `kubernetes`). The key is mentioned alongside the group description. The key is `kubernetes`). The key is mentioned alongside the group description. The
ConfigMap-based configuration is flat and does not allow non-leaf keys. ConfigMap-based configuration is flat and does not allow non-leaf keys.
@ -46,7 +54,6 @@ They will be deprecated and removed in the future.
Variable names are underscore-separated words. Variable names are underscore-separated words.
## General ## General
Those are top-level keys, containing both leaf keys and groups. Those are top-level keys, containing both leaf keys and groups.