Thanks. So does your environment folder structure only contain modules, or have you put the clients and services module areas into the environment folder structure too? What does your clients and services areas look like?
For now I've created different environment areas only for modules, and have thought about maybe going for something like "c_<project>::<environment>::<serverRole>" type of class structure, so that I can build different server configurations for the different projects, environments and server roles. On other words, my clients area would look something like this: - "c_projectA", in which the classes "c_projectA::prod::webserver", "c_projectA::qass::webserver" and so forth would be implemented (and added to the node definition for the relevant servers) - "c_projectB", in which the classes "c_projectB::dev::database", "c_projectB::testing::database" and so forth would be implemented (and added to the node definition for the relevant servers) - etc I haven't thought out all the details yet, but I believe something like this would make having multiple server setups manageable. Any thoughts on this kind of setup? Kenneth On Tue, Aug 3, 2010 at 1:16 PM, Ohad Levy <[email protected]> wrote: > maybe this thread can > help: http://groups.google.com/group/puppet-users/browse_thread/thread/838480ef7394bc79/72b48b4b1ea6a0e5?lnk=gst&q=Ideas/Best+Practices+for+module+versionin#72b48b4b1ea6a0e5 > Ohad > > On Tue, Aug 3, 2010 at 7:00 PM, Kenneth Holter <[email protected]> > wrote: >> >> We're a subversion shop, so we're using subversion for this type of >> thing (although I'd like to try out Git). We've created a few simple >> scripts for tagging modules and such, so I belive we have a neat >> solution to version control of our code. >> >> But structuring the code itself (as was the original topic for this >> thread) is of course equally important. We have multiple projects each >> consisting of multiple server types/roles and environments (dev, test, >> qass, prod), and need our clients and services areas to reflect this >> in a dynamic and structured way. Having a base/generic class like >> Christian proposed is the way to go, but I would like to hear from >> others how they have organized the clients and services areas. >> >> >> - Kenneth >> >> On Tue, Aug 3, 2010 at 7:37 AM, Jeff McCune <[email protected]> wrote: >> > On Mon, Aug 2, 2010 at 4:50 AM, Kenneth Holter <[email protected]> >> > wrote: >> >> >> >> Let me briefly mention that we're going to use external nodes to tell >> >> which environment (prod, qass, ...) a node belongs to, and use the >> >> build in puppet enironments to separate code between the environments >> >> (production clients will pull modules from a different module area >> >> than clients in for example qass, and so forth). >> > >> > The organization of using environments in puppet with module paths >> > referencing multiple, different working copies of the same version >> > control repository checked out to different branches works quite well >> > for many people. >> > >> > Git is particularly good in this case since it's designed to quickly >> > switch the working copy among branches quickly and easily. Doing so >> > in git doesn't result in a different filesystem path which is >> > convenient when setting the modulepath in each environment. >> > >> > -- >> > Jeff McCune >> > http://www.puppetlabs.com/ >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Puppet Users" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]<puppet-users%[email protected]> . >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<puppet-users%[email protected]> . >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<puppet-users%[email protected]> . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
