I'd like to propose that we stop using servergroups as a subdir in our puppet manifests dir.
proposal is just: move all .pp files over to 'services' and remove servergroups subdir entirely.
justification: 1. the distinction between servergroups and services is..... blurry. 2. the actual usage difference between them is confused - if only b/c we have things which could be services in servergroups and servergroups in services. 3. the distinction doesn't actually buy us anything we don't get with just services.
alternative proposal: - since services tend to be module-represented in puppet more than in manifests, we could move to having:
manifests/ nodes <-- actual node definitions like we have now attributes <-- attributes nodes can include (essentially services but with a less confusing name vis-a-vis our modules/* services)
Thoughts?
-sv
1. the distinction between servergroups and services is..... blurry.
So if we wanted to spin up several load balancers we'd have first create a node definition for each balancer then add the proper services to the node definitions. This seems to be the reverse of what is done now with the host being assigned a servergroup which has services defined for what the "group" does. Am I incorrect in my understanding? If not, then there will probably be slightly more work involved to setup multiple hosts doing the "same" thing, no?
alternative proposal:
It does help make things clearer and much more "granular" but let's say one host has a minor difference in how the service is configured, we would have to accomodate the tweak somehow either by cloning a service definition and making the new definition specific to the host or by adding in extra modifications using another specification file.
I guess both seem equal to me but the enhanced granularity/readability of your proposal would probably help with self-documentation and managability. That is of course if my understanding of the setup is correct. :-)
On Thu, 2011-06-09 at 11:59 -0400, Adam M. Dutko wrote:
- the distinction between servergroups and services is..... blurry.
So if we wanted to spin up several load balancers we'd have first create a node definition for each balancer then add the proper services to the node definitions. This seems to be the reverse of what is done now with the host being assigned a servergroup which has services defined for what the "group" does. Am I incorrect in my understanding? If not, then there will probably be slightly more work involved to setup multiple hosts doing the "same" thing, no?
My issue is - explain to me the difference between that and a service?
Really, anything that's NOT node-specific configuration is just an attribute that the node can include - or an attribute of an attribute or a collection of attributes.
in pseudo-code: server = Node(Seth.fedoraproject.org) server.httpd = True server.createrepo = True server.mock = True server.tcp_allows = [22, 80, 443]
Now the httpd attribute may be comprised of a bunch of other commands/attributes/declarations - but still - just an attribute.
I'm not trying to take away ANY of our configurations we have AT ALL right now. I'm trying to just move it so there isn't the hesitation when trying to figure out where to put things.
alternative proposal:
It does help make things clearer and much more "granular" but let's say one host has a minor difference in how the service is configured, we would have to accomodate the tweak somehow either by cloning a service definition and making the new definition specific to the host or by adding in extra modifications using another specification file.
okay? and? We do that now, don't we? How is this different?
really, all I'm suggesting here is moving files around.
-sv
My issue is - explain to me the difference between that and a service?
I was mainly trying to show both approaches end up with the same result ... attribute clutter. There really isn't a way to work around it, but keeping things readable/granular like your suggesting helps.
okay? and? We do that now, don't we? How is this different?
In reality... it's very similar.
really, all I'm suggesting here is moving files around.
Makes sense. Niriks link (http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Best_Practice) helps too.
On Thu, 2011-06-09 at 12:05 -0400, seth vidal wrote:
alternative proposal:
It does help make things clearer and much more "granular" but let's say one host has a minor difference in how the service is configured, we would have to accomodate the tweak somehow either by cloning a service definition and making the new definition specific to the host or by adding in extra modifications using another specification file.
okay? and? We do that now, don't we? How is this different?
really, all I'm suggesting here is moving files around.
okay - I've merged/mv'd the files in puppet master from servergroups to services and I've modified site.pp to reflect that.
this is ONLY in master/production and it is DONE.
I was starting to do it in staging and I thought "hmm, is now a good time to go ahead and move staging away from a branch and into main-line?"
the plan here would be to take all the staging bits and move them into either separate class definitions and/or subdirs (for the config files) so that we don't ever have merge/cherrypick issues between the two branches.
thoughts? -sv
On Thu, Jun 9, 2011 at 16:56, seth vidal skvidal@fedoraproject.org wrote:
On Thu, 2011-06-09 at 12:05 -0400, seth vidal wrote:
alternative proposal:
It does help make things clearer and much more "granular" but let's say one host has a minor difference in how the service is configured, we would have to accomodate the tweak somehow either by cloning a service definition and making the new definition specific to the host or by adding in extra modifications using another specification file.
okay? and? We do that now, don't we? How is this different?
really, all I'm suggesting here is moving files around.
okay - I've merged/mv'd the files in puppet master from servergroups to services and I've modified site.pp to reflect that.
this is ONLY in master/production and it is DONE.
I was starting to do it in staging and I thought "hmm, is now a good time to go ahead and move staging away from a branch and into main-line?"
the plan here would be to take all the staging bits and move them into either separate class definitions and/or subdirs (for the config files) so that we don't ever have merge/cherrypick issues between the two branches.
something like?
development/ staging/ production/
thoughts? -sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Thu, 2011-06-09 at 17:54 -0400, Stephen John Smoogen wrote:
On Thu, Jun 9, 2011 at 16:56, seth vidal skvidal@fedoraproject.org wrote:
On Thu, 2011-06-09 at 12:05 -0400, seth vidal wrote:
alternative proposal:
It does help make things clearer and much more "granular" but let's say one host has a minor difference in how the service is configured, we would have to accomodate the tweak somehow either by cloning a service definition and making the new definition specific to the host or by adding in extra modifications using another specification file.
okay? and? We do that now, don't we? How is this different?
really, all I'm suggesting here is moving files around.
okay - I've merged/mv'd the files in puppet master from servergroups to services and I've modified site.pp to reflect that.
this is ONLY in master/production and it is DONE.
I was starting to do it in staging and I thought "hmm, is now a good time to go ahead and move staging away from a branch and into main-line?"
the plan here would be to take all the staging bits and move them into either separate class definitions and/or subdirs (for the config files) so that we don't ever have merge/cherrypick issues between the two branches.
something like?
development/ staging/ production/
or maybe:
/ == production staging in a subdir development in a subdir
Does that make sense?
-sv
On Fri, Jun 10, 2011 at 00:21, seth vidal skvidal@fedoraproject.org wrote:
On Thu, 2011-06-09 at 17:54 -0400, Stephen John Smoogen wrote:
On Thu, Jun 9, 2011 at 16:56, seth vidal skvidal@fedoraproject.org wrote:
On Thu, 2011-06-09 at 12:05 -0400, seth vidal wrote:
something like?
development/ staging/ production/
or maybe:
/ == production staging in a subdir development in a subdir
Does that make sense?
It makes sense.. it is at that point what colour the bikeshed you want versus how big you want to build it. My tastes are different but I can adapt as long as I can stick in my bike:).
-sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Fri, 10 Jun 2011 00:21:23 -0400 seth vidal skvidal@fedoraproject.org wrote:
something like?
development/ staging/ production/
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.
kevin
On Fri, Jun 10, 2011 at 6:03 AM, Kevin Fenzi kevin@scrye.com wrote:
On Fri, 10 Jun 2011 00:21:23 -0400 seth vidal skvidal@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
On Thu, Jun 9, 2011 at 09:48, seth vidal skvidal@fedoraproject.org wrote:
I'd like to propose that we stop using servergroups as a subdir in our puppet manifests dir.
proposal is just: move all .pp files over to 'services' and remove servergroups subdir entirely.
justification: 1. the distinction between servergroups and services is..... blurry. 2. the actual usage difference between them is confused - if only b/c we have things which could be services in servergroups and servergroups in services. 3. the distinction doesn't actually buy us anything we don't get with just services.
servergroups -> services sounds good servergroups -> servers (multiple replication) sounds bad.
just in case people are confused .. servergroups really should be servicegroups ;) so the transition makes sense.
alternative proposal: - since services tend to be module-represented in puppet more than in manifests, we could move to having:
manifests/ nodes <-- actual node definitions like we have now attributes <-- attributes nodes can include (essentially services but with a less confusing name vis-a-vis our modules/* services)
Thoughts?
-sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
infrastructure@lists.fedoraproject.org
-
Adam M. Dutko -
Kevin Fenzi -
Seth Vidal -
Stephen John Smoogen -
Toshio Kuratomi