Support for multiple Hostnames defined in annotation

[jrnt30]

As an enhancement it would be nice to support having multiple hostnames defined in the annotation for services similar to the KOPS DNS controller.

Example:
external-dns.alpha.kubernetes.io/hostname: "redis.dev.vpn,elasticsearch.dev.vpn"

Use Case:
This might be somewhat of a unique case, but we are attempting to create an NGinx ingress controller resource that can handle multiple services simultaneously.

One limitation we have found with the NGinx Ingress Controller is that for TCP and UDP proxying you have to use a configmap to register the port -> <namespace>/<service>:<containerPort> mapping for the Nginx controller to read.

What this has resulted in is that the NGinx Controller's service (which is the ELB) actually should be "responsible" for defining via the annotation all of the services that are mapped in this way, since there is no explicit Service or Ingress resource.

[hjacobs]

@jrnt30 sounds reasonable. External DNS should eventually replace the KOPS DNS controller, so it makes sense to support the same feature set.

[linki]

Sounds good to me.

Does anyone have alternative ideas on the spec? A comma-separated list seems fine as DNS names don't include commas, I guess.

@jrnt30 Do you want to tackle this yourself?

[jrnt30]

I am traveling this week @ the client site. When I get back I can take a look at tackling this.

…

On Mon, May 8, 2017 at 4:34 AM Martin Linkhorst ***@***.***> wrote: Sounds good to me. Does anyone have alternative ideas on the spec? A comma-separated list seems fine as DNS names don't include commas, I guess. @jrnt30 <https://github.com/jrnt30> Do you want to tackle this yourself? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#197 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWanDKmzBIippZqmtqCPbW1owAmAurFks5r3u_EgaJpZM4NSflt> .

[mtanski]

route53-kubernetes supports multiple hostnames so this will be needed for compatibility with it (since it's planned)

[linki]

@mtanski Didn't know. Thanks for telling us.

[ideahitme]

@jrnt30 are you available to implement this ?

[ideahitme]

addressed in #256