On Tue, Oct 16, 2012 at 9:16 PM, Rob Sweet <[email protected]> wrote:
> Hi, guys. > > I've been trying to dig through the group backlog to understand what > the vision is for using module versioning and it's not clear to me how > versions for modules are intended to be used in the future. I'll lay > out some details about my setup and how I would envision using module > versions and maybe some of those 'in the know' would be willing to > comment. > > The basic idea is that it would be possible to include a specific > version of a module and to have multiple versions of a module exist in > my manifests at the same time. I'm sure this has been talked about > before. It's very similar to using Bundler/Gemfiles with Ruby when > you have multiple versions of a gem installed. > > - 56 Puppet environments, basically a matrix of applications and > deployment environments > > - 1 SA group responsible for building new boxes, managing system-level > services and configs, troubleshooting OS-level problems, etc. > > - 8+ application groups that all have different release schedules and > want to make whatever Puppet changes they require and release those > changes as they release their applications. > > Obviously, the tricky part is doing independent releases without the > forks/branches. I'm trying to avoid having a ton of branches/forks of > my manifests around because that makes it really hard for the SA group > to push changes in an organized way to each environment. If they had > a change to push out to update resolv.conf, for example (yes, yes, use > DHCP, that's a whole different fight), It would suck to have to make > that change and then merge it to all of these forks/branches to > actually push it out. > > It seems like Bundler-style autoloading would really help with this. > Group A needs to make some changes to the Foo module. Group B also > uses the Foo module and while they want the changes that Group A > proposes, releasing those changes to their servers needs to be > coordinated with an application change to support the changes. It > would be great if the AppA module could include Foo-2.0.0 and the AppB > module could include Foo-1.2.3 until they're ready to use the new > changes. Both versions of the module would exist in my moduledir > until it's reasonable to retire v1.2.3. No extra branches/forks of > the manifests needed (except for testing purposes). > > So is this approach crazy? Is this where versioning/autoloading is > going? Is anybody working on something like this? Can I help? > > Thanks! > I had something very similar to that in 2008 :) and I've presented it in the first puppetconf, always feeling most people didnt get it ;) my original slides are at [1] and would be happy to talk more about it :) sadly videos from puppetconf 2009 are not availavble online anymore. Ohad [1] http://www.slideshare.net/ohadlevy/puppetcamp-how-puppet-helped-us-to-standardize-communicate-and-work-together > Rob Sweet > Manheim > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" 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-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
