hi seth,<br>I prefer to maintain the whole apache configs in debian style. Where I have base apache module for minimal setup + sites-available + mods-available, and individual use cases (passenger /mod_wsgi etc or virtualhosts/proxypasses) are modelled as dependant modules of apache where they selectively enable/disable sites or mods. Individual mods are loaded by separate .load file and configured by separate .conf files. Also we have separate puppet sub modules for individual mods. This way i can readily assemble my node specific apache configs without tampering the base puppet modules even if they need fin grained customizations.<br>
<br>regards<br>ranjib<br><br><div class="gmail_quote">On Wed, Jun 8, 2011 at 10:19 AM, seth vidal <span dir="ltr"><<a href="mailto:skvidal@fedoraproject.org" target="_blank">skvidal@fedoraproject.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
A problem I've been having recently is how we configure/maintain our<br>
webserver configs in puppet. Right now we use a common class that has<br>
definitions for a all the common functions/setups we use for our apache<br>
setups. It's good from a programmatic code-reuse standpoint to make sure<br>
we're not having to make N edits all over the place. It's bad b/c it<br>
makes it next to impossible to know that when you edit<br>
<br>
httpd::proxy in modules/httpd/manifests/init.pp that you're going to<br>
impact the following systems:<br>
proxy*<br>
puppet*<br>
collab*<br>
secondary*<br>
<br>
Since we run so many different kinds of websites and types of website<br>
services I'm going suggest we stop thinking of 'httpd' as the base layer<br>
and start thinking of the name of website itself as the base layer.<br>
<br>
so instead of 'httpd' the module you'd care about would be:<br>
<br>
'<a href="http://infrastructure.fedoraproject.org" target="_blank">infrastructure.fedoraproject.org</a>'<br>
<br>
or<br>
<br>
'<a href="http://proxy.fedoraproject.org" target="_blank">proxy.fedoraproject.org</a>'<br>
<br>
etc, etc<br>
<br>
<br>
The advantage is - if I want to modify infrastructure - I don't have to<br>
worry if my modification will change things on other systems I'm not<br>
aware of. It lets people make changes quickly, safe and confident that<br>
they are only modifying the site they think they are modifying.<br>
<br>
The disadvantage is we may have to make certain kinds of changes in a<br>
number of places when we want to make a change.<br>
<br>
I personally, think I'm better at running git-grep to know where else<br>
has the same config than I am at parsing puppet configs in my head to<br>
know what is or is not actually using a specific import.<br>
<br>
I'm not sold on how this dir structure should be setup, yet and I'm<br>
curious for some feed back.<br>
<br>
thoughts?<br>
<br>
-sv<br>
<br>
<br>
_______________________________________________<br>
infrastructure mailing list<br>
<a href="mailto:infrastructure@lists.fedoraproject.org" target="_blank">infrastructure@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/infrastructure" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/infrastructure</a><br>
</blockquote></div><br>