Serverset namer can't resolve shard fragment

[JustinVenus]

Issue Type:

• [ X] Bug report
• [ X] Feature request

What happened:
I was not able to resolve a name in the form of /service/prod/read:http#0

What you expected to happen:
I expected to get shard member 0 for service label http of the Path(/service/prod/read).

How to reproduce it (as minimally and precisely as possible):

1. configure linkerd to use serversets.
2. try to resolve a dtab in the dtab playground on the admin interface with a shard like #0

Anything else we need to know?:
It seems like the functionality could be added here and would allow the namer to behave inline with upstream finagle.

Environment:

• linkerd/namerd version, config files: ANY configured for serversets
• Platform, version, and config files (Kubernetes, DC/OS, etc): Mesos/Aurora
• Cloud provider or hardware configuration: AWS

[JustinVenus]

If this functionality is useful I'd be happy to code it up and submit a PR.

[cpretzer]

@JustinVenus a contribution would be awesome!

I'm not familiar with shards, is this for zookeeper?

[JustinVenus]

@cpretzer serversets have a json payload on the znode in zookeeper. The format is roughly like the following.

{"status": "ALIVE", "additionalEndpoints": {"http": {"host": "host1", "port": 31238}}, "serviceEndpoint": {"host": "host1", "port": 31238}, "shard": 0}

Most serverset implementations (that I am familiar with) are able to advertise the shard (aka instanceId). The default/upstream finagle implementation of the ServersetNamer allows one to craft a dtab to specify a given shard/instanceId.

My use case is to prefer a primary instanceId with the ability to failover to a standby like the following example.

/srv/foo => /zk/prod/read:http#0 | /zk/prod/read:http#1 | !   

[cpretzer]

Got it! Thanks for teaching me something new 😀

[cpretzer]

Resolved with #2391