Hi Al, et al. I apologize for being so late to this party but I'm loving all the conversation around this. I've read through the Google Doc and found lots of cool ideas on class parameter names. Please forgive me though, my product manager wired brain wants to pause at this point and discuss it a bit first before I offer my opinions on the doc.
On Tue, Jun 18, 2013 at 11:19 AM, Alessandro Franceschi <a...@lab42.it> wrote: > For me a module is reusable when: > 1- It supports many different OS (this is somehow implicit and does not > involve naming conventions) > 2- It leaves to the user freedom on how to populate and customize the > provided configuration files ( I think this is the main point for most > reusability cases) > 3- It allows the user to manage some behaviours of the module (has a > service to be restarted after a file change? Do I want to manage a service > status (at runtime or boot) > 4- In (somehow extreme) cases it allows the user to customize names of > package/services, paths of files and so on > 5- It allows seamless addition of custom resources, not managed by the > module but related to it > 6- It allows the user to decide where to place his data (also this is out > of naming convention scope) > I'll admit that this is my Forge biased view of things, but I'm working towards modules that are reusable, interoperable and introspectable. It would help me contribute to the discussion if we could hammer out whether we loosely agree on the goal and definitions. I'm already pretty happy with your definition of reusable, but I'll paraphrase. Interoperable - Module A is known to do X, Y & Z. - Module B also does X, Y & Z and can seamlessly replace module A Reusable - Supports multiple operating systems with a clear & standard pattern for adding additional OSes - General capabilities of module can be switched on or off or lightly modified. Ex., don't manage services or override configuration directory. One way that we differ immediately on reusability is that you're pretty detailed on what you should be able to customize, like package and service names. I don't disagree with you but I'm trying to start from a higher level and see whether that's sufficient. I'm not sure what the balance is regarding # of class parameters in use / ease of use. Introspectable - Code follows style guide and other patterns so that contributions are more easily made and managed. - Puppet should be able to programmatically tell us about defined class parameters and their default values. (yeah, this is theoretical atm) Are these three goals and their values what we're all striving for with this proposal? If not, what am I missing or getting wrong? Thanks for kicking this off Al. I also care deeply about this stuff and will be trying to carve off more time each week to help you continue to explore it. -- Ryan Coleman | Modules & Forge | @ryanycoleman | ryancoleman in #puppet -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
