Modules are not overkill and are, in fact, the only way you can do what you
intend.
There is currently no module structure that would allow you organize your
manifests the way you'd like and still be able to apply classes flexibly.
The reason for this is that the module structure in puppet is mostly a file
naming convention that allows the master to locate particular classes. If
you wish to flexibly include/declare classes as you wish, the only way
puppet would be able to find them and flexibly apply them would be to
follow the module convention.
For instance, for a class nginx, the *only* place puppet can find that and
apply it flexibly is if it is located in $moduledir/nginx/manifests/init.pp.
Otherwise, you'd have to still rely on import and then have a *ton* of
conditionals everywhere to figure out whether to actually apply each class.
This is not maintainable at all.
Go with modules. You'll have many fewer issues later.
On Monday, March 11, 2013 12:23:47 PM UTC-6, Andrea Crotti wrote:
>
> So far we have a similar situation, for each different server one fabric
> and one puppet file, where the fabric file simply applies it in a brutal
> way.
>
>
> with settings(user='root'):
> put('qa.pp', 'qa.pp')
> put('puppet apply qa.pp')
>
> And puppet files don't use anything like classes or modules, but simply:
>
> package {["nginx", "python-virtualenv", "rsync", "autossh",
> "redis-server", "git-core", "python-dev", "ntp"]:
> ensure => installed}
>
> service { 'nginx' :
> ensure => "running",
> enable => true,
> hasrestart => true,
> require => Package["nginx"]
> }
>
>
> Now there are many issues with the current setup, where the first is we
> are not really managing our servers, but we can only provision them..
>
> The second big problem is that there is a lot of repetition everywhere
> and the third is that I can't easily provision multiple services on a
> single machine (if they were supposed initially to run on different
> machines).
>
> Now I read some doc and in theory it looks like I should create one
> module per each service.
>
> - nginx
> + templates
> + manifests
>
> - couch
> + templates
> + manifests
>
> this is however overkill for me, what I think would make more sense
> would be
>
> - templates
> + nginx
> + couch
>
> - manifests
> + base.pp
> + couch.pp
> ..
>
> Is it possible to use such a structure though?
>
> I just want to be able to use classes smartly, avoid duplication and
> start working with puppetmaster instead of this silly way..
>
> Any advice?
> Thanks
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
