ross
commented
7 years ago @craigwatson - Unfortunately this PR was just the first bits of the transition. After I didn't hear anything back for a while it ended up being completed and tested in a fork without backwards compatibility. That's been used since and has worked well and should be able to handle the recent config changes in consul-template, but we haven't tried it out yet.
I originally aimed to maintain backward compat, but that was quickly becoming more trouble than I had time to sort though. Now that it's a finished, tested, and working you may be able to use the fork as a basis for implementing a version that is or the other option would be to do a major version bump and break compat. I'd imagine it may go smoother for someone who knows the original code well.
If we get back to something here that works like the fork with a config-hash I'd happily look at de-forking the next time I'm in that code.
This maintains backwards compatibility with the named params, but defaults their values to undef. All of the validations and behaviors have been maintained. The advantage of this approach is that arbitrary configuration can be passed through to the config file similar to how the consul module works. This way each new param doesn't have to be individually added before the module will support it, requiring PR's & releases, and updates to use them.
I plan to look at doing the same sort of thing with the consul_template config as well if it's of interest. I wanted to push this up so it'd be easier to see what I was after before doing that as it'll be quite a bit more involved with the way all that is set up. I hopefully can maintain backwards compatibility there as well. Thoughts?