Support consul-template

[EvanKrall]

It'd be nice if this module supported consul-template

I'm thinking this would be a consul::template resource, with source, destination, command, etc. parameters. We'd also need to manage the consul-template service, which will involve making an init script, etc.

[solarkennedy]

Yea. One thing I would not want to see is the pattern where some modules accept an erb path directly, don't do that please.

The end product should look like this I think:

# Put loadbalanced webs in the MOTD for fun
file { '/etc/motd.ctmpl':
  content  => 'I serve these webs: {{range service "web"}}{{.Node}} {{end}}'
} ->
consul::template { '/etc/motd':
  target  => '/etc/motd', # (redundant)
  source  => '/etc/motd.ctmpl',
  command => "wall 'MOTD IS CHANGED!!! RELOGIN TO SEE IT ASAP!!!'"
}

I guess if you wanted to be super fancy you could support a "content" parameter directly into the define, and it would store it in a temp location. content and source would be mutually exclusive I guess. That would allow people use use erbs directly if they really wanted to.

Do we want to support the "once" method of creation instead of daemon? Would anyone really want that? (you get the slowness of puppet and the dynamic-ness of consul?)

[EvanKrall]

How about if the resource simply accepts content =>, and then the caller can call with content => template("mymodule/mytemplate.erb") or content => file("mymodule/myfile")?

I definitely agree that the daemon mode is more exciting that the "once" mode, but I could see it being useful. Maybe you've already got puppet code configuring some service, and you want to stick some variables into that config that comes from consul. (Never mind that this particular example could also be implemented as a custom function letting you do consul lookups from inside puppet, which we could also write.) If it's straightforward to also do once, then we should do that too; if it's tricky (e.g. idk how you create a temporary file with puppet) then I'd be fine taking our time for once and just doing daemon mode now.

[solarkennedy]

Yea, I guess in a sense we are writing a thing that replaces the "file" type, so we should respond to the same types of arguments.

This means content or source. You can't do just content=>file() without a third party module...

[solarkennedy]

Apparently the file() stuff is still not resolved
https://tickets.puppetlabs.com/browse/PUP-1214

[KrisBuytaert]

https://github.com/Intelliplan/puppet-consul_template is s module that already does that .. it could be intergrated id neede.

[EvanKrall]

I like the idea of making a thin wrapper around the module that @KrisBuytaert mentioned, so a consul::template resource would create a consul_template::template resource.

We could even have our consul::template resource include the consul_template class, setting class parameters (consul agent host and port) based on parameters to our consul class.

This thin wrapper wouldn't quite provide the API I was hoping for (with the content parameter):

Do note that putting the ctmpl file in place place is outside of this module scope. It can e.g. be done in the profile.

I think I can live with that.

[hopperd]

Has there been any traction on this. I think it would be worth while to have this support self contained in one module without having chained dependencies for this functionality. It would also be nice to possibly add support for consul replicate as well.

[solarkennedy]

Nope, mostly just waiting for someone with the need to do it.
@EvanKrall with your most recent project, I know you used templates, did you use that consul_template module or did you do something else?

[hopperd]

I'm approaching the need right now so I might add it, I'll wait to hear back from @EvanKrall on what he used.

[eliranbz]

Is it still planned? an amazing-to-have feature

[hopperd]

I think that this probably make sense as a separate module and I've been using this one:
https://github.com/gdhbashton/puppet-consul_template

[solarkennedy]

Yea, I don't think we should re-invent the wheel. I agree that this would be best as a separate module, as it has a different install/config/service/etc.