Parameters

The parent key for all the following parameters is openshift4_config.

globalPullSecrets

type

dict
default

{}

An alias for pullSecretCustomization.auths.

Entries from both parameters are merged; entries from pullSecretCustomization.auths win if the same registry host is configured in both. New configuration should use pullSecretCustomization.auths, which keeps all pull secret configuration in one place. The component emits a trace message when this parameter is used.

pullSecretCustomization

type

dictionary
default 
pullSecretCustomization:
  enabled: true
  label: 'pull-secret.openshift-config.syn.tools/include'
  auths: {}

Configures the Espejote ManagedResource which keeps the cluster’s global pull secret (pull-secret in namespace openshift-config) up to date.

The ManagedResource collects the auths entries of every labelled secret in namespace openshift-config, adds the entries from pullSecretCustomization.auths on top, and merges the result into the cluster pull secret. Entries which aren’t contributed by any of those sources are left untouched, so the component coexists with the OpenShift installer and with other controllers which maintain their own entries.

Because the ManagedResource also watches the cluster pull secret itself, manual edits of the managed entries are reverted automatically.

pullSecretCustomization.enabled

type

boolean
default

true

Whether to deploy the ManagedResource.

pullSecretCustomization.label

type

string
default

pull-secret.openshift-config.syn.tools/include

Other components can create secrets in the openshift-config namespace with their own pull-secret. If they label those secrets with this key, they get merged into the final pull-secret.

The component reads the auths field of the secret’s .dockerconfigjson and nothing else. Labelled secrets without a .dockerconfigjson field are skipped, so a mislabelled secret can’t break the reconciliation.

If several labelled secrets set the same registry host, the secrets are sorted ascibetically by metadata.name and later ones win. Entries from pullSecretCustomization.auths take precedence over entries from any labelled secret.

Changing this parameter doesn’t remove entries which were merged under the old label. The ManagedResource only ever adds or overwrites entries. Set the registry host to null in pullSecretCustomization.auths to remove an entry.

See Use Secrets to merge cluster pull secret entries for a worked example.

pullSecretCustomization.auths

type

dict
default

{}
example 
pullSecretCustomization:
  auths:
    docker.io:
      email: dockerhub@example.com (1)
      auth: ?{vaultkv:${cluster:tenant}/${cluster:name}/openshift4-config/docker.io-pull-secret} (2)
    cloud.openshift.com: null (3)
1 Some registries require an email address to be present for authenticated pulls.
2 We strongly recommend that you store the auth value for the registry in Vault.
3 Setting a registry host to null removes its entry from the cluster pull secret.

The pull secret entries configured through the cluster hierarchy. This allows customizing the cluster pull secret without having to replicate the complete secret contents in Vault.

The component expects entries in the dict to be valid entries for the .dockerconfigjson auths field. Entries with a null value are removed from the cluster pull secret, including entries originally created by the OpenShift installer. This is how you opt out of remote health reporting, for example.

The component deploys these entries in the Espejote JsonnetLibrary appuio-pull-secret in namespace openshift-config. They’re merged after any labelled secret, so they take precedence.

The component doesn’t base64-encode the value provided for auth. Please make sure that you store the auth value as base64 in Vault.

caBundle

type

string
default

null
example 
caBundle: | (1)
  -----BEGIN CERTIFICATE-----
  MY AWESOME CA
  -----END CERTIFICATE-----
1 Custom CA deployed as ConfigMap syn-ca-bundle.

This parameter allows to deploy a ConfigMap in the openshift-config namespace. The ConfigMap contains the configured CA in the key ca-bundle.crt, to be used by other components.

This ConfigMap isn’t used by OpenShift components. OpenShift uses a separate config map called user-ca-bundle in namespace openshift-config to extend the system wide trusted CA bundle. See parameter trustedCA in component openshift4-proxy for details on how to deploy additional trusted CA certificates for the system-wide trusted CA bundle.

cloud

type

string
default

null

The cloud provider on which the cluster is running. Currently, the component only looks at this parameter to check whether to manage vSphere credentials, see also parameter vsphere.

vsphere

type

dictionary
default

{"vcenterURL": null, "username": null, "password": null}

The vSphere credentials for the cluster.

If parameter cloud is vsphere, the component verifies that none of the fields are null and deploys a secret appuio-vsphere-creds in namespace openshift-config. The contents of that secret are preformatted to work as contents for secret vsphere-creds in namespace kube-system. The component needs the vCenter URL because the secret fields must be named <vcenter-url>.username and <vcenter-url>.password. In addition to the secret the component also deploys an Espejote ManagedResource in namespace openshift-config. The ManagedResource copies the contents of secret appuio-vsphere-creds to secret vsphere-creds in namespace kube-system.

We deploy a custom secret and a ManagedResource so that the vSphere credentials are not directly embedded into the ManagedResource’s `spec.template on the cluster.
If parameter cloud isn’t set to vsphere, the contents of this parameter are ignored.

motd

type

dictionary

Configure OpenShift’s message of the day which is displayed in the terminal when using oc login.

motd.messages

type

dictionary
default

{}

A dictionary of messages to be displayed in the message of the day. Entries with null values are skipped. This allows users to remove notifications which were configured higher up in the hierarchy.

motd.include_console_notifications

type

boolean
default

false

Whether to include the console notifications from component-openshift4-console in the message of the day.

The component will include each console notification’s spec.text and spec.link contents in the following form:

<spec.text>
<spec.link.text>: <spec.link.href>

For console notifications which don’t provide spec.link, the second line will be omitted.

etcdCustomziation

type

dictionary

This parameter allows customizing the cluster’s etcd. The implementation uses Espejote to reconcile our customizations for the etcd.operator.openshift.io/cluster resource.

etcdCustomization.enabled

type

boolean
default

false

Whether to deploy the Espejote managed resource on the cluster. If this parameter is set to false, changing the contents of etcd.spec has no effect.

etcdCustomization.spec

type

dictionary
default

See class/defaults.yml

A partial spec for the OpenShift 4 Etcd custom resource. See the upstream API documentation for available fields.

networkCustomization

type

dictionary

This parameter allows customizing the cluster’s networking. The implementation uses Espejote to reconcile our customizations for the networks.config.openshift.io/cluster and networks.operator.openshift.io/cluster resource.

networkCustomization.enabled

type

boolean
default

true

Whether to deploy the Espejote managed resource on the cluster. If this parameter is set to false, changing the contents of networkCustomization has no effect.

networkCustomization.labelConfig and networkCustomization.labelOperator

type

string
default 
labelConfig: 'network.openshift-config.syn.tools/include-config'
labelOperator: 'network.openshift-config.syn.tools/include-operator'

Other components can create configmaps in the openshift-config namespace with their own spec for the cluster resources. If they label those configmaps with these keys, they get merged into the final configuration.

For more information, see Use ConfigMap to merge Networking Config.

The ManagedResource collects all configmaps and sorts them by name before merging the specs into the configuration. The config specified in this component will have precedence over any conflicting config in the configmaps.

networkCustomization.specConfig and networkCustomization.specOperator

type

string
default 
specConfig: {}
specOperator: {}

This are the specs for the resources networks.config.openshift.io/cluster and networks.operator.openshift.io/cluster.