RouteGroup support

[szuecs]

RouteGroup are supported by skipper and kube-ingress-aws-controller.
In order to automate DNS for this CRD type we have to implement a new source.

CRD details:

• The status is similar to ingress
• The spec has a list of hosts

Example:

apiVersion: zalando.org/v1
kind: RouteGroup
spec:
  backends:
  - name: first
    serviceName: myapp
    servicePort: 80
    type: service
  defaultBackends:
  - backendName: first
  hosts:
  - my-rg1.example.org
  - myapp.example.org
  routes:
  - pathSubtree: /api
status:
  loadBalancer:
    routegroup:
    - hostname: kube-ing-lb-.......lb.$cloudvendor.com

I will soon send a PR for this @linki @njuettner

[Raffo]

While I'm not opposed to that, I would encourage to try to see if we can find a way to make this a plugin or opt in via build tags. I understand the value of this for zalando, but this crd is new and still not widely used in the community. I would love to avoid supporting very specific company centric implementations.
I know a similar reasoning can be done for istio, but it's a bit more widespread (no matter the quality of the project).

[szuecs]

I opened a discussion issue in #1447.
TBH the RouteGroup CRD is not used as long as it has no support in the full tool chain that is used by our LB stack.
I know, that there are a couple of companies relying on skipper, kube-ingress-aws-controller and external-dns as a stack. Right now external-dns is the missing piece in this offering.
Of course we don't have the marketing power of the competitors, but I don't think we should help the big ones even more. I think it would be wrong to only support the big cloud providers or judge based on that.

[Raffo]

I know, that there are a couple of companies relying on skipper, kube-ingress-aws-controller and external-dns as a stack. Right now external-dns is the missing piece in this offering.
Of course we don't have the marketing power of the competitors, but I don't think we should help the big ones even more. I think it would be wrong to only support the big cloud providers or judge based on that.

I don't think we are being biased towards cloud providers. The early support of Istio's CRD was probably a mistake but now it's in and there isn't much that we can do for now. We can evaluate in the future what to do with it based on how #1447 will evolve.
There is no distinction being made in the way this project is managed that is based on what "big cloud providers" want rather than what smaller contributors want and this has to be clear.
As you can see from #1435 or other issues, it's could easily be not sustainable to add all CRDs and it's worth exploring what possibilities we have.

TBH the RouteGroup CRD is not used as long as it has no support in the full tool chain that is used by our LB stack.

I'm sorry for that. I'm willing to bring the conversation in #1447 further depending on availability and I'm open to set up a call as early as next week if you think it would be helpful to brainstorm a solution together. Of course, I can suggest you to use a temporary fork of External DNS, with the goal of not having you rely on it for too long as this would be clearly a failure for the project itself.

[szuecs]

I think PRs can be independently merged from #1447 and if the decision is to remove all CRDs or everything after date X, I am fine to have the routegroups source to be removed.

WDYT?

[Raffo]

I don't see any problem with that. I think we should hold on merging additional CRDs aside from this one to avoid having problems bringing them out.

[hjacobs]

@szuecs I think there are even more implications around rolling out RouteGroup within Zalando, many tools currently rely on Ingress (e.g. hjacobs/kube-resource-report#129) and need to be adapted. I also use Ingress hostnames for dependency detection via OpenTracing's peer.hostname span tag. Let's discuss in person.

[szuecs]

RouteGroup support was merged, so this issue can be closed