Supply the set of instances for a given VIP address

[seh]

At present, fargo allows one to request and monitor a set of instances associated with a Eureka application, but there's no similar means to request or monitor of set of instances associated with a VIP address. Define new functions that use the /eureka/v2/vips/{address} and /eureka/v2/svips/{address} resources via the GET verb.

Sketching, we'd expand fargo's exported interface with the following:

• Polling
  • *`func GetInstancesForVIPAddress(address string) ([]Instance, error)`**
  • *`func GetInstancesForSecureVIPAddress(address string) ([]Instance, error)`**
• Consuming
  • type InstanceSetUpdate
  • func ScheduleInstanceSetUpdatesForVIPAddress(address string, await bool, done <-chan struct{}) <-chan InstanceSetUpdate
• Caching
  • type InstanceSetSource
  • *`func NewInstanceSetSourceForVIPAddress(address string, await bool) InstanceSetSource`**
  • *`func NewInstanceSetSourceForSecureVIPAddress(address string, await bool) InstanceSetSource`**

The latter two groups mimic what we did in #37 for applications. The names get unwieldy; I could live with some contractions, such as "instances" instead of "instance set", and "SVIP" instead of "secure VIP address".

Best would be to just implement the first "polling" set, then move on with the other two.

[seh]

I've implemented the first "polling" capability, but I'm at a loss how to get the fargo tests to run. Perhaps that's fodder for a separate issue, but attempting to follow the directions using the three Docker containers described here in the README.md file still leaves me with clients that can't get expected responses from the two Eureka servers.

I'd like to write tests, but I don't want to do so if I can't get them to run myself. @atharvai and @ryansb, do the fargo tests work for you when run in the third Docker container (the one with image tag "hudloss/fargo:master")?

[seh]

It turns out my attempts to test against Eureka version 1.3.1 were bitten by a known compatibility problem (#29). I'll move along with my tests for the "polling" capability.

[seh]

Fighting against the Eureka server's response cache makes testing difficult, if not impossible, without introducing lengthy delays between writes and confirming reads. Even adjusting the server's configuration with values like the following doesn't help.

eureka.responseCacheAutoExpirationInSeconds=1
eureka.responseCacheUpdateIntervalMs=100

How has this project dealt with these kinds of timing failures in the past? Do the tests ever pass?

[seh]

Pull requests #54, #55, and #57 (someone else snuck in there and got 56) wrap up my intended work.

I wound up extending the idea of querying a set of instances—optionally filtered by status and shuffled—to cover not just VIP addresses, but applications too. In most cases with which I'm familiar a client wants to keep track of instances, regardless of their grouping axis.