Add support for custom reference resolvers

[jfhamlin]

This change adds support for custom reference parameters. Previously only references to the outputs of other stacks were supported. Now a parameter value may refer to a file with File: <path>. A user may also define her own custom resolver by defining a class Stacker::Resolvers::<ResolverType>Resolver and providing a hash with a single key, <ResolverType>, as the value of a parameter. The directory containing resolver definitions must be provided to stacker with the --resolvers argument.

    parameters:
      StackParam:
        Stack: OtherStack
        Output: OutputName
      FileParam:
        File: path/to/file

[kainosnoema]

This is looking really interesting. I like the idea of making resolvers a documented API, so new ones can be created pulling from various sources.

Couple thoughts this brings to mind:

1. An approach that might make things a bit easier to manage and version is to use RubyGems to pull in other resolvers instead of file path and require. Could suggest a convention such as stacker-resolver-<name>, or similar. Then you just install the ones you need for your stacks, and the community can build and maintain them. I could see resolvers for S3 and other third-party data sources.
2. Another thing to consider in the API is allowing the resolver to know which region + stack is asking for the param—could certainly be added in the future, but might be a breaking change.

[jfhamlin]

Another thing to consider in the API is allowing the resolver to know which region + stack is asking for the param—could certainly be added in the future, but might be a breaking change.

Resolvers actually do take the region as a constructor argument: def initialize(ref, region). We can add the stack later as a non-breaking change.

[jfhamlin]

An approach that might make things a bit easier to manage and version is to use RubyGems to pull in other resolvers instead of file path and require

Agreed. Happy to rip out the path support and leave this for later if that's your preference. I don't feel strongly about the path support right now.

[jfhamlin]

Updated. Removed path support to narrow the API changes involved.