[KubeIngressProxy] Add KubeIngressProxy.ingress_specifications

[dolfinus]

This allows to add host field to ingress rules, and also set tls field in ingress specification. Alternative implementation of #406, should fix #404.

Next step of dividing #648 into smaller pieces

[consideRatio]

Ah now I see this involved a reference to host.

Should this be spec.get("host") or host instead though? I'm not sure at all, just wanted to make sure that at least one of us is sure about what makes sense.

[consideRatio]

Yeah I think this is currently weird, considering how spec["host"] is referenced in the tls section.

[dolfinus]

It is complicated.

From the one hand, routespec can contain hostname only if Jupyterhub.subdomain_host is not empty. If Jupyterhub.subdomain_host="example.com" then Hub is running on example.com, services on services.example.com and servers on {username}.example.com/{server}, and all these domains are set in the routespec.

From another hand, Ingress tls and host can contain wildcards:
https://kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards

I'm not sure which option has higher priority

[consideRatio]

Since this only affects the KubeIngressProxy part etc, I figure we go with what you think makes sense here - but maybe you could add a comment about this as this is apparently quite tricky?

[consideRatio]

Overall, this PR LGTM, but this makes me uncertain.

I don't overview when host is None, or if there are implicit assumptions about what ingress_specification can and can't be, such as setting just tlsSecret and not the host etc, and if passing host=None is acceptable or not here.

If a comment clarifies it, even though its a comment indicating that we are not sure, that is a clear improvement on managing this complexity I think.

[dolfinus]

IMHO, the best way here is to merge host from routespec with items from ingress_specifications to cover all the cases. But I'm still not sure about the way of merging these values.

For example, routespec=https://my.example.com/me/service and ingress_specifications=[{"host": "*.example.com", "tlsSecretName": "some-secret"}]. Do we need to create:

spec:
  rules:
    - host: my.example.com
      path: /me/service
    - host: *.example.com
      path: /me/service
  tls:
    hosts:
      - *.example.com
    secretName: my-secret

or

spec:
  rules:
    - host: *.example.com
      path: /me/service
  tls:
    hosts:
      - *.example.com
    secretName: my-secret

or

spec:
  rules:
    - host: my.example.com
      path: /me/service
  tls:
    hosts:
      - *.example.com
    secretName: my-secret

?

[dolfinus]

Options 1 and 2 can lead to the following issue.

Example:

c.Jupyterhub.subdomain_host="example.com"
c.KubeIngressProxy.ingress_specifications = [{"host": "*.example.com", "tlsSecretName": "secret-name"}]

For user1 and user2 Jupyterhub will create routespec="https://user1.example.com/default-server" and routespec="https://user2.example.com/default-server" respectively.

But then both ingress rules will look like:

spec:
  rules:
  - host: *.example.com
    path: /default-server
  tls:
    hosts:
    - *.example.com
    secretName: secret-name

and path resolution will be ambiguous.

So I've implemented option 3 which produces rules like:

spec:
  rules:
  - host: user1.example.com
    path: /default-server
  tls:
    hosts:
    - *.example.com
    secretName: secret-name

and added some tests covering these cases.

[consideRatio]

❤️ 🎉 🌻 thanks @dolfinus for helping me understand this better and providing comments so that maintenance in the future is simplified! This LGTM!