On Nov 22, 2014 4:22 AM, "Gareth Rushgrove" <gar...@morethanseven.net> wrote:
> I'd love some feedback on this PR, which adds the private function to > the puppet-module-skeleton that a bunch of people use. > > https://github.com/garethr/puppet-module-skeleton/pull/43 ... > And I'm on the fence too. Any thoughts? As a general principle, I'm not crazy about not being able to use the x::install or x::service classes independent of the main class or whatever the "expected" interface is. x::config or auxiliary subclasses I could see. Being able to use the subclasses is an important feature for migrating to using the module, either from an unmanaged system, a different module or even a different configuration management tool. For example, my work environment is a legacy Cfengine shop and we still have quite a number of EL5 systems co-managed with Cfengine[1]. As I add the ability to manage some service in Puppet, I can easily do so for new, pure-Puppet systems. But for systems managed originally w/Cfengine, I might not want to redo the configuration in the way that it's done with the Puppet module, but I can at least switch the service and package portions to using Puppet. Maybe this is just another facet of my belief in "don't be a proprietorial asshole with data" and my preference for OO languages that have no "private" concept, only naming conventions. [1]. I have a script that reads /var/lib/puppet/classes.txt and makes Cfengine classes by prepending "puppet_" and transforming "::" to underscores. Then I litter the legacy Cfengine with !puppet_x_service or whatever. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMmm3r4caRLmP%2B73ksNmsXdg04x30ZLsXECsw4fzXLuoXULbrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
