Hi John, Thanks for your reply!
On 15.4.2013 18:02, jcbollinger wrote: > 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. That makes sense. > 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. It is not website related components, but indeed web-server - vhost definitions, special apache configuration files (e.g. module configuration overrides, etc). Besides, the apache was just an example, I have other cases where similar setup is required. In any case, the project-specific definitions are *only* for resources, directly related to the module in question (in this case, apache). > 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. > Pardon my wording. By subclasses, I just meant a class inside some module (apache::projectX). No inheritance involved. If single point of entry can be avoided, then what do you think about the second part of my question? : > 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. BR, Boyan
signature.asc
Description: OpenPGP digital signature
