On Fri, Jun 10, 2011 at 6:03 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Fri, 10 Jun 2011 00:21:23 -0400 > seth vidal <skvidal@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure