LEGO_SUPPORTED_INGRESS_CLASS doesn't seem to work

[unixwitch]

Either that or I'm missing something.

I configured kube-lego (0.1.4) like this:

        - name: LEGO_DEFAULT_INGRESS_CLASS
          value: trafficserver
        - name: LEGO_SUPPORTED_INGRESS_CLASS
          value: trafficserver

If I'm reading the documentation right, this should make it only handle Ingresses with no class or where the class is trafficserver, and if the Ingress has no class, it will set trafficserver as the class on its own Ingress.

However, at startup it says:

time="2017-05-24T11:13:38Z" level=info msg="kube-lego 0.1.4-67fb438e starting" context=kubelego
time="2017-05-24T11:13:38Z" level=fatal msg="Unsupported default ingress class: 'trafficserver'. You can set the ingress class with 'LEGO_DEFAULT_INGRESS_CLASS'" context=kubelego

So it seems like there's a hardcoded list of Ingress classes that are supported, perhaps nginx and gce?

I know that the GCE Ingress controller violates the Ingress spec in how it uses path and needs special handling, but most other Ingress controllers (as far as I know) should work the same way as nginx; it seems reasonable that if the Ingress class isn't recognised, it should be handled the nginx way by default.

[sigxcpu76]

Here's the hardcoded list.

https://github.com/jetstack/kube-lego/blob/84d1eec4de97b326c4f9ea9812b8c5539b2121f1/pkg/kubelego_const/consts.go#L24

[munnerz]

Now that #202 is merged, you should be able to hack around this limitation and at least test out the nginx implementation with whatever other ingress controller.

To do so, try setting the following annotations on your ingress:

kubernetes.io/ingress.provider: nginx
kubernetes.io/ingress.class: trafficserver

You'll then need to set LEGO_SUPPORTED_INGRESS_PROVIDER=nginx and LEGO_SUPPORTED_INGRESS_CLASS=trafficserver. You'll also need to be using the :canary image tag for kube-lego, as there's not been any releases of kube-lego containing this change yet.

[unixwitch]

I've worked around this in the mean time by configuring my Ingress controller to handle the "nginx" class, but that has the problem that if someone wants to run my controller and the nginx controller in parallel, they will both handle the same Ingresses.

If I understand #202 right, there is now a separate annotation for ingress.provider (i.e., implementation) and ingress.class has become a way to give arbitrary names to multiple instances of the same provider. So my controller still has to pretend to be the nginx provider but I can set a different class than the "real" nginx controller.

I think this is a better way of handling it, but I still don't like the hardcoded list of providers, which I understand hasn't changed. This may need to wait for resolution of kubernetes/ingress#555, but in the mean time, I still think assuming any unknown provider has the "nginx" behaviour is the right thing to do. (Because the nginx behaviour matches what the Ingress spec actually says.)

[dElogics]

Confirmed.

[cceckman]

+1, from a slightly different use case: I'd like to run 'staging' and 'prod' ingress controllers, and send some traffic to each. But it looks like that won't work today.