Allow ip resolver to know for which vm other vm is being resolved

[elyast]

Such feature is needed, in case we would like to resolve ip addresses in different way depending which node resolves other nodes.

Sample use case

When setting up cluster across different regions (in EC2 or eucalyptus) we would like to resolve nodes within the same region by private ip, and nodes that are in different region by public ip and therefore we need information which node is resolving which one.

[pbitty]

Interesting - you are giving different machines their own DNS view.

There are a couple of things I think we should tweak before merging this:

• make the current_machine parameter last in the call to the custom_resolver Proc, so that it's backwards-compatible with the current signature, and is optional for people who don't need the parameter
• update the README accordingly, maybe just appending to the current bit about the custom resolver, showing the second usage (and explanining when current_machine is nil)?

I am wondering if there is a better way to name the custom_resolver parameters so that it's more clear what each one is? eg. resolved_guest/current_guest or resolved_machine/current_machine

I like using the word guest' because then it's more clear that when managing the host, 'guest' will be nil. I'm just tossing out ideas here. :)

What do you think?

/cc @smdahlen @bdcribbs

Thanks for the contribution.

[elyast]

I can adapt changes and README, should we check if custom ip resolver is accepting two or one parameters? to avoid spoiling existing Vagrantfiles?

[pbitty]

From what I understand, Procs don't do strict argument checking so you can send them as many arguments as you want.

[pbitty]

eg. you are able to do this:

foo = proc { |x| puts x }

foo.call(1)
# 1

foo.call(1,2,3,4,5)
# 1

foo.call()
# [blank output since x is nil]

So, for people who have the old custom_resolver signature, it should still work fine.

[elyast]

Added couple of tweaks we were talking about

[pbitty]

Merged. Sorry for the long delay. Thanks @elyast.