proposal: stop using servergroups in puppet

[Toshio Kuratomi]

On Fri, Jun 10, 2011 at 6:03 AM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Fri, 10 Jun 2011 00:21:23 -0400
> seth vidal <skvidal at fedoraproject.org> wrote:
>> or maybe:
>>
>> / == production
>> staging in a subdir
>> development in a subdir
>>
>> Does that make sense?
>
> Sure. Makes sense to me.
>
> I would say the / == prod makes more sense as thats what is going to be
> getting the most changes.
>
> Can we get feedback from those folks who use staging for testing the
> most? Toshio? Paul?
>
> I think this will save us branch confusion and merge pain, and
> hopefully be not too much hassle for people merging changes from a stg
> host back to production.
>

We talked about this on IRC since silly me just read the message.
Conclusion is roughly that:
* separate branches where some staging configs (for nodes, for
instance) goes in the master branch is confusing
* git is confusing
* template conditionals on environment (stg vs prod) can serve the
same niche as branches for letting us easily merge changes between
staging and production.

So skvidal, nirik, mdomsch, and I are all for making staging a directory.

The new method of doing testing would be:
* modify the configs in the staging directory.
* commit && push
* test on stg
* cp file from staging to production directory for that service
* commit && push
* make sure prod functions as expected

For changes that are supposed to remain different between staging and
production, use templates with environment conditionals.  For
instance, from pkgdb.cfg.erb:

<% if environment == "staging" %>
base_url_filter.base_url = "https://admin.stg.fedoraproject.org"
<% else %>
base_url_filter.base_url = "https://admin.fedoraproject.org"
<% end %>

We also had a side conversation about abuse of templates and pretty
much agree that we've been using templates to put together disjoint
services just because they are built from the same rpm package (for
instance, postfix for @fedoraproject.org mail vs postfix for
lists.fedorahosted.org mail or our many uses of httpd).  On paper,
this keeps us from duplicating work if we need to make changes
globally to all installations of that rpm package.  In practice, it
has lead to us making changes to all installations of that package
when we only intended to change the one for a specific service.  It
makes sense for us to start thinking of modules as separated by the
services that we provide rather than the rpm package that they come
from in the future and shifting templates, modules, and inheritance
accordingly.

-Toshio