On Nov 22, 2014 4:22 AM, "Gareth Rushgrove" <[email protected]> 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 [email protected]. 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.
