Error logs with msg "empty args for matcher Host"

[kernel164]

Bug Report

What did you do?

setup maesh 1.2.0 in EKS.

What did you see instead?

too many error logs with msg "empty args for matcher Host"

Output of mesh log: (1.2.0)

maesh-mesh-4spq4 maesh-mesh 2020-05-31T02:33:08.392792516Z time="2020-05-31T02:33:08Z" level=error msg="empty args for matcher Host, []" entryPointName=http-5000 routerName=logging-aes-kibana-443@http

What is your environment & configuration (arguments, provider, platform, ...)?

• EKS 1.19
• aes-kibana 443 is an external service of type = "ExternalName" in logging namespace.

[kernel164]

Any quick workaround for this?

[jspdown]

I have been able to reproduce the bug consistently. I discovered multiple problems while reproducing this bug:

• ports is no required on a Service of type ExternalName. But the ShadowServiceManager is expecting them to have at least one. Resulting in an error in the logs:

time="2020-06-05T07:31:14Z" level=error msg="Unable to complete work \"default/my-service\": unable to sync shadow service: Service \"maesh-my-service-6d61657368-default\" is invalid: spec.ports: Required value"

• Service of type ExternalName doesn't have a ClusterIP, which is used when generating the Host rule in the dynamic configuration. The output is invalid:

"routers": {
      "default-my-service-80": {
        "entryPoints": [
          "http-5000"
        ],
        "middlewares": [
          "block-all-middleware"
        ],
        "service": "block-all-service",
        "rule": "Host(`my-service.default.maesh`) || Host(``)",
        "priority": 1
      },

@kernel164 Thanks for reporting this, this service type is currently not supported on Maesh.

Any quick workaround for this?

As it is right now, the only workaround I can suggest is to put your ExternalName service in a dedicated namespace and specify this namespace in the ignoreNamespaces option of the controller.

[jspdown]

Adding support for this type of Service would be challenging and its behavior would be different than other services:

• Can't use TrafficTarget to authorize traffic as there's no destination pods you could target. So, in ACL mode, either we authorize everything (would be counter-intuitive) or we don't but in this case the service will never be reachable.
• ExternalName services don't require ports to be defined. These ports are essential for shadow-services. We would have to find a new strategy to provide name.ns.maesh addresses when there's no ports.

For now, we are going to avoid evaluating these services, to prevent breaking the configuration of Traefik instances.

Follow-up issue for supporting ExternalName services: #622.