Manifests layout

[shatei]

Hello there, at first lemme thank you for the work on puppet module for consul_template.

I'm a bit concerned about puppet modules from external sources using init.pp as i see it very disadvantegous. For example in my projects i tend to manage external modules in separate projects from my internal modules. Basicaly i'm 'sourcing' external modules into my internal for later use so when i upgrade from external source, i need to fix far less things.

I suggest to get rid of the init.pp manifest and let everyone 'source' separate steps. I don't get it why i need to go through the whole process of initializing consul_template when i, for example, want to register a new config on server, that is already watching another configs.

Please, let me know if this does make sense to you. I have some time to spare so i can create new layout of modules to separate base instalation (user, package, consul-template configuration) from registering new config to watch for (template dir, config dir, purge, etc.).

[craigwatson]

Hi Shatei,

Thanks for raising this, however using init.pp is standard practice among Puppet module writers, so we will be keeping this layout.

If you would like the module to not purge any existing configs, you can set the purge_config_dir parameter to false when using the module, for example:

class { 'consul_template':
  purge_config_dir => false,
}

Or by using Hiera:

include ::consul_template

consul_template::purge_config_dir: false

Hope that helps, please feel free to reopen this issue if not.

Thanks, Craig

[shatei]

But get this. I have a common profile included on all of my servers. Just to ease things i want to include consul-template in this profile so i want just basic installation to happen, no config files to watch for now. Then i have puppet modules for applications (postgres, haproxy, pgbouncer for example) where i want to declare just new config to watch for.

With the layout being as it is today, it's pretty easy to write the basic installation of consul-template, just don't specify any config in $watches hash right? But the in the puppet modules for application servers i want to call just watch.pp basicaly cause everything else was done in common profile. I have no other option than go through the whole init.pp again, but now with something in $watches hash. It's extremely painful and unclear to write modules like this (see for example this https://github.com/puppetlabs/puppetlabs-postgresql no init.pp at all). Another example might be a need to create two configs in two separate puppet modules used on same server.

I think that it makes sense to omit init.pp and separate process into two runtimes - one for installation consul-template and other for declaring new config files to watch for. Or maybe in init.pp just handles basic installation than watch.pp can be public class.

As i'm reading this message back, it might seem offensive in some parts, but it's just the way i'm used to write comments so please don't get offended by it. I want just to consult issue i came across by when creating new resources for my infrastructure.

Thank you .)