Parameters

The parent key for all of the following parameters is espejote.

namespace

type

string
default

syn-espejote

The namespace in which to deploy this component.

manifests_version

type

string
default

${espejote:images:espejote:tag}

The Git reference to the controller deployment manifests. The default is the tag of the controller image.

images

type

dictionary
default

See class/defaults.yml

The images to use for this component.

resources`

type

dictionary

default

See class/defaults.yml

The resources of the deployment.

jsonnetLibraries

type

dictionary
example 
jsonnetLibraries:
  my-lib: (1)
    metadata: ... (2)
    spec:
      data:
        foo.libsonnet: "{}" (3)
  myns/my-lib: {} (4)
1 The name of the jsonnet library. Can be a namespaced name <namespace>/<name>. If not namespaced, the library is created as a shared library for all managed resources to use.
2 The metadata of the jsonnet library (optional).
3 The library data. The import path of the library is [lib/]<JsonnetLibrary name>/<key in .spec.data>. The lib/ prefix is added if the library is shared.
4 Namespaced library. Only available to the managed resources in the same namespace. Imported with <name>/<key> without the lib/ prefix.

The jsonnet libraries to deploy. Can be shared, if set without namespace prefix or namespaced if the key contains a namespace prefix.

managedResources

type

dictionary
default

{}

The managed resources to deploy.

The keys are parsed as namespaced names <namespace>/<name> and used as names and namespaces of the managed resource. If no namespace is provided the managed resource is created in the fallback namespace provided in the namespace parameter.

managedResources.<name>.metadata / managedResources.<name>.spec

type

dictionary
example 
managedResources:
  my-namespace/copy-configmap: (1)
    metadata: ... (2)
    spec: ... (3)
1 The key is parsed as a namespaced managed resource <namespace>/<name>.
2 The metadata of the managed resource (optional).
3 The spec of the managed resource (required).

The metadata and spec of the managed resource.

The component will automatically create the service account for the managed resource. If no service account is provided in the spec, the component will create a new one with the same name as the managed resource.

The component will automatically create roles and cluster roles (and their bindings) to read the resources defined in the triggers and context keys of the managed resource.

The library guesses the resource name and scope from the kind. Those parameters can’t be guessed reliably without access to the cluster API. The guess can be overridden with the _namespaced: bool and _resource: string settings.

triggers:
- name: irregular-resource
  watchResource:
    _resource: sheep
    _namespaced: true
    apiVersion: cattle.farmersdelight.io/v1
    kind: Sheep

managedResources.<name>._roles / managedResources.<name>._clusterRoles

type

dictionary
example 
managedResources:
  my-namespace/copy-configmap:
    _roles:
      configmaps: (1)
        rules:
        - apiGroups:
            - ""
          resources:
            - configmaps
          verbs:
            - list
            - get
            - create
            - ~delete (2)
      otherns/configmaps: (3)
        rules:
        - apiGroups: [""]
          resources: [configmaps]
          verbs: [delete]
    _clusterRoles:
      namespaces:
        rules:
        - apiGroups:
            - ""
          resources:
            - namespaces
          verbs:
            - list
    metadata: ...
    spec: ...
1 The name of the role or cluster role. Can be a namespaced name <namespace>/<name> or <name>. The name part is used as the name of the role or cluster role. If no namespace is given, the role is created in the same namespace as the managed resource.
2 The verbs and resources prefixed with a tilde ~ are removed from the resulting rule, even if they’re configured higher up in the configuration hierarchy.
3 A role with name and namespace.

The keys of the _roles and _clusterRoles are the names of the roles and cluster roles to create. The names are prefixed with the namespace and the name of the managed resource to prevent name collisions. The values are the manifests of the roles and cluster roles. A role binding or cluster role binding is automatically created for the roles and cluster roles with the service account of the managed resource.

managedResources.<name>._clusterRoleBindings / managedResources.<name>._roleBindings

type

list
example 
managedResources:
  my-namespace/copy-configmap:
    _clusterRoleBindings:
      - cluster-admin (1)
    _roleBindings:
      - my-role (2)
    metadata: ...
    spec: ...
1 The name of an existing cluster role.
2 The name of an existing role in the given namespace.

The _clusterRoleBindings and _roleBindings keys have the same behavior, one creates role bindings for the given roles and the other creates role bindings for the given cluster roles.

alerts

type

dictionary
example 
alerts:
  BadThingsHappening:
    enabled: true
    rule:
      annotations:
        description: Bad things have been happening on {{$labels.node}} for more than 10 minutes.
        message: Bad things have been happening on {{$labels.node}} for more than 10 minutes.
        runbook_url: https://hub.syn.tools/openshift-upgrade-controller/runbooks/BadThingsHappening.html
      expr: |
        bad_thing_happening == 1
      for: 10m
      labels:
        severity: warning

alerts defines the alerts to be installed. The dictionary key is used as the name of the alert.

alerts.<name>.enabled

type

bool

Defines whether to install the alert.

alerts.<name>.rule

type

dict

Holds the configuration of the alert rule.

See Prometheus Alerting Rules for details.

Example

managedResources:
  my-namespace/inject-configmap:
    metadata:
      annotations:
        description: |
          Adds a config map called test to any namespace with the label "managedresource-sample.espejote.io/inject-cm".

          If the reconcile was triggered by a trigger as defined in `triggers` it only renders the required config map.
          If the trigger is unknown or the managed resource itself was changed all config maps are rendered and applied.
    spec:
      serviceAccountRef:
        name: espejote-inject-configmap
      triggers:
      - name: namespace
        watchResource:
          apiVersion: v1
          kind: Namespace
          labelSelector:
            matchExpressions:
            - key: managedresource-sample.espejote.io/inject-cm
              operator: Exists
      context:
      - name: namespaces
        resource:
          apiVersion: v1
          kind: Namespace
          labelSelector:
            matchExpressions:
            - key: managedresource-sample.espejote.io/inject-cm
              operator: Exists
      template: |
        local esp = import "espejote.libsonnet";
        local samplelib = import "jsonnetlibrary-sample/sample.libsonnet";
        local namespaces = esp.context().namespaces;

        local cmForNs = function(ns) {
          apiVersion: 'v1',
          kind: 'ConfigMap',
          metadata: {
            name: 'test',
            namespace: ns.metadata.name,
          },
          data: {
            sample: samplelib.Sample,
            nsLabel: std.get(ns.metadata.labels, "managedresource-sample.espejote.io/inject-cm"),
          },
        };

        if esp.triggerName() == "namespace" then [
          cmForNs(esp.triggerData().resource),
        ] else [
          cmForNs(ns) for ns in namespaces
        ]