Unable to add different module configuration for Ambassador Edge Stack multi-setup

I have a multi-setup of Ambassador Edge Stack (eg: ambassador-external and ambassador-internal) and both setups live in the same namespace so they can share CRD’s, AuthService and RateLimitService. Using the ambassador_id you should be able to apply object to a given (or both) setups. Unfortunately as far as I can tell, we’re not able to create multiple Modules to apply different config for every setup

---
apiVersion: getambassador.io/v2
kind: Module
metadata:
  name: ambassador-external
spec:
  ambassador_id: [ "ambassador-external" ]
  config:
    server_name: ambassador-external
    diagnostics:
      enabled: false
---
apiVersion: getambassador.io/v2
kind: Module
metadata:
  name: ambassador-internal
spec:
  ambassador_id: [ "ambassador-internal" ]
  config:
    server_name: ambassador-internal
    diagnostics:
      enabled: true

It seems the above config is not picked up by any of the setups but when I use the module and specify the name ambassador it does

---
apiVersion: getambassador.io/v2
kind: Module
metadata:
  name: ambassador
spec:
  ambassador_id: [ "ambassador-external", "ambassador-internal" ]
  config:
    server_name: ambassador
    diagnostics:
      enabled: true

I’m under the impression Ambassador only picks up/reads the module with a fixed ambassador name. Even if I would specify only one ambassador_id the config will only be applied to one setup. Unfortunately this prevents us from creating multiple modules as every module needs a unique name. Ideally we should be able to configure both setup module differently.

I’m using following versions:

• Ambassador Edge Stack helm chart v6.1.1
• Ambassador Edge Stack image v1.1.0
• AWS EKS with Kubernetes v1.14.8

[tribonacci]

@tribonacci could you give an example of how you managed to get it working on a service annotation? I have had no luck so far.

@lawliet89 This is my ambassador service yaml file.

apiVersion: v1
kind: Service
metadata:
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind:  Module
      name:  ambassador
      ambassador_id: xxxx
      config:
        service_port: 443
        resolver: endpoint
        load_balancer:
          policy: round_robin
      ---
      apiVersion: ambassador/v1
      kind: Module
      name: tls
      ambassador_id: xxxx
      config:
       server:
         enabled: True
         alpn_protocols: h2
         redirect_cleartext_from: 80
         secret: xxxx-certificate
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
  name: ambassador-xxxx
  namespace: xxxx
spec:
  externalTrafficPolicy: Cluster
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    service: ambassador-xxxx
  type: LoadBalancer

[jasons42]

We are experiencing this issue as well after transitioning from module annotations to CRD’s.

This behaviour appears to be hard-coded here: https://github.com/datawire/ambassador/blob/08c8ea0e3c62e13c0404d6adc5dceaefce1ff8b6/python/ambassador/ir/irambassador.py#L129 https://github.com/datawire/ambassador/blob/08c8ea0e3c62e13c0404d6adc5dceaefce1ff8b6/python/ambassador/ir/irambassador.py#L164

We run multiple Ambassadors with configurations specific to the application they are fronting so need to be able to configure them at a per-deployment level.

There is nothing in the documentation to suggest that the name ambassador is required for Module resources or that they can only be configured globally when using CRD’s versus per deployment using the annotation method.

We are going to have to migrate back to using annotations now.