On Wed, Feb 2, 2011 at 12:37 AM, donavan <[email protected]> wrote: > On Jan 30, 3:54 pm, Nigel Kersten <[email protected]> wrote: >> After feedback, we decided to use Redmine to track design proposals >> and feedback, so here is the new location. >> >> http://projects.puppetlabs.com/issues/6079 >> >> This is an important problem for us all to solve. Feedback is important. > > Left first pass feedback. I suspect I may have missed some previous > discussion, especially wrt the new DSL concerns. Just let me know if > I'm late to the game on that point.
No, your feedback was great. Concrete examples of modules that implement this would be a really useful thing to add to the design. > On a related note is there a similar discussion about 'vendor'ing > puppet modules? I see sites needing to extend/override classes for > local requirements, like $operatingsystem support. This was one of the main problems I was trying to solve with this design actually. Say an Author releases a module to manage a service "foo". They know how to abstract away stuff so that it works on RedHat and Debian, and provide an internal PDL for their module that tells you what "foo_socket" and "foo_config_file" are for those platforms. If you want to make this work on some more exotic OS, as a User you simply have to provide the correct values for your OS. This isn't going to work in all cases. You might need to patch the original module to abstract away certain concepts, but it should get us a long way towards the goal I think. It's certainly possible you can hack around these sort of limitations by creating your own module that pokes inside the "foo" module and inherits from classes there, overriding resources, etc etc, but that feels to me like writing code to a private API. You generally shouldn't do it... and you should instead modify the original module and associated "public API" to do what you need in a supported fashion. Does that make more sense? I think with an implementation like the proposed design we can start to treat the class parameters and defined types of a given module as an actual public API for that module, rather than mucking around in the internals. > > -- > 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.
