Instruct url info to be put into configmap

Overview

When following a gitops-model, it is beneficial to get a deterministic URL for endpoints. Although we cannot control the service endpoint names in EnMasse (2 address spaces could end up creating conflicting ones), it would be useful if a tenant can instruct a configmap to be created with the endpoint information (url, ports, CA).

Design

The AddressSpace resource would be extended to support the following syntax:

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  endpoints:
  - name: messaging
    service: messaging
    exports/bindings:
      - kind: ConfigMap
        name: myconfig // Requires the 'system:serviceaccount:enmasse-infra:address-space-controller' service account RBAC rule to be created by application owner.
        namespace: mynamespace // Defaults to namespace of address space
      - kind: Secret
        name: mysecret
      - kind: Service
        name: myservice

The Secret/ConfigMap will contain the the following fields:

data:
  service.host: messaging-....svc
  service.port.amqp: 5672
  service.port.amqps: 5671
  // Following is only populated if endpoint is exposed
  external.host: ...
  external.port.amqps: 443

Service format:

kind: Service
...
spec:
  type: ExternalName
  # Points to the existing service in the enmasse-infra namespace
  externalName: messaging-....enmasse-infra.svc.cluster.local
  ports:
  - port: 5672
  - port: 5671

Tasklist

[lulf]

@k-wall ConfigMaps, Secrets and Services are objects that better integrates with Kubernetes compared to an AddressSpace, and partially because we don’t want applications to dictate the service names inside enmasse-infra (since there are multiple applications that could conflict). Therefore, an application would have to read the address space object to know the actual endpoint url.

For instance, lets say you have an application repo with all YAML for address spaces and addresses. Now, in order for the application code to have zero knowledge of Kubernetes and its API (which it would need to retrieve the address space resource), it can instead depend on environment variables that can reference fields in a configmap or a secret.

An application will then consist of:

• a deployment manifest for the application itself where the env for the container references a configmap ‘foo’
• an RBAC rule to allow EnMasse to manipulate the configmap in the applications namespace
• an address space manifest with the export to configmap ‘foo’

The application code can then only depend on environment variables to retrieve the information about endpoints.

Similarly, the service case is similar, where the application depends on a service with a known name ‘mymessaging’ and configures the address space export to create it. The application code can then just connect to ‘mymessaging’ without knowing the actual service url.

[lulf]

@k-wall Good question. I think doing a replace would be a convenient behavior, and allow us to reoncile the config should something change, i.e. in an upgrade scenario where we added another port for instance. I don’t expect this would happen frequently.