On Monday, April 15, 2013 5:02:06 AM UTC-5, Boyan Tabakov wrote: > > Hi all, > > Let's consider the following situation: > > I use the module structure, proposed by R.I.Pienaar: > > http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php > > > I have a module, let's say apache, that follows that pattern for > installing and setting up basic apache server. > > However, I also want to have a way to provide extra configuration for > specific use-cases. Let's call these projects. So for each project, we > want to have some additional class apache::projectX that performs these > additional tasks (e.g. deploys more specific template, defines more file > resources, etc, etc). > > My question is this: if I want to stick with a single point of entry to > the module (i.e. manifests include just apache module with some > parameter), what's the best way to go considering that each project > subclass may have its own set of parameters? Defining all these > parameters on the apache class itself, doesn't sound like a good idea. > Perhaps, defining them in Hiera as apache::projetX::parameterY? > > The easy solution seems to be to forget about single point of entry and > include from manifests both the apache and the apache::projectX classes > with appropriate parameters. However, in order to ensure proper > sequencing all the apache::projectX classes might need to contain some > code like this: > > Class['apache::config'] -> > Class['apache::projectX'] ~> > Class['apache::service'] > > I don't like the idea of having this in all project-specific classes, as > modification of the module structure might become more difficult - i.e. > will need to change all the apache:projectX classes if I want to add, > let's say, a apache::modules class that needs to load before the projectX. > > Any thoughts on a best practice in similar situations? > >
Single point of entry does not serve well and is not a particularly useful goal when the desired results are very divergent. The single declaration then becomes magical, and therefore difficult to understand and maintain. I think your specific case is even more distinguished than that, however: it sounds like you are inappropriately modeling web *site* components (i.e. content) as part of the web *server*. I would pull the projects out as completely separate modules (and that could restore your single point of entry, on a per-module basis). Yes, your project modules might need to declare some relationships, but that is in no way a function of which module contains each class. Note also that you should *not* be using subclasses for any of what you described. It's not clear whether you actually are doing so, despite your use of the term, but Puppet class inheritance is a very special- (and limited-)purpose tool that does not apply to any of the needs you described. It looks like you may simply be putting some classes in others' namespaces, however, and that's an *entirely* different thing. John -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
