On Sunday, June 30, 2013 10:21:44 PM UTC-5, Ryan Coleman wrote: > > 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 > >
That sounds eminently reasonable at the high level, but I'm not sure what it really means for module implementations. I suspect that what you and Al are both getting at is that module interfaces should provide a consistent higher-level language built on top of Puppet DSL. Certainly choosing parameter names in a consistent way advances that goal. I see potential issues there, however, with class names, which conceivably differ from one module to another, whether simply by the choice of the author or as a result of differing module structure. For example, consider two modules managing Puppet, one that provides a single front-end class by which agent and master can both be managed, and one providing separate classes for managing those services. Although it might not be exactly difficult to switch from one to the other, doing so surely would involve more than just pulling one out of the module path and putting the other in. It would involve more even than also universally changing the name of one or two referenced classes. Would these two hypothetical modules therefore fail to be "interoperable" as you see it? Perhaps you mean something different by "seamlessly". To me, interoperability means largely that modules managing different subsystems can be deployed and used alongside one another without interfering with each other, either in terms of managed resource collisions or in terms of requirements. If one can replace one module with another without creating these sorts of problems then that could be construed as "seamless", but it seems a little tangential to the line of discussion (and one that we've had before). I still think the Puppet would be very well served by a facility such as we discussed here: https://groups.google.com/forum/#!topic/puppet-users/Fvl0aOe4RPE (naturally, I prefer my own proposal in that thread). Were something like that available, I think it would have a significant impact on best practices for module implementation, and some impact on best practices for module interfaces. Inasmuch as it needn't change any existing Puppet behavior, it could even be added to the Puppet 3 series. > > 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. > > I'm with you as far as that goes, and I think starting with high-level principles is an advantageous approach. I do think the reusability question to which Al and I devoted so much rhetoric rises to this level, or at least near it -- specifically, whether the "reusability" objective demands that module interfaces be implemented in terms of parameterized classes. I appreciate that you may not want to come down on one side or the other at this point, and I'm not asking you to do, but I do observe that nothing among the criteria you so far advanced for this principle demand parameterization. I suppose Al's point (6) addresses the question for him. He and I differ on whether that's an appropriate criterion for reusability (regardless of whether it is a good or bad idea for some other reason), so that's something that you will eventually need to settle for yourself. > > 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) > > Even if you suppose that classes will generally be parameterized, wouldn't it be reasonable to want to introspect explicit hiera() calls as well? Even parameterized classes may in some cases perform them. > > 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? > > I think they are all eminently worthy goals, though among them they considerably expand the scope of the current discussion as I previously perceived it. I do not doubt that Al had broader ideas than the ones with which he started this thread, however. Like Al, I would not necessarily have come up with introspection as a goal -- and I'm not sure it rises to the same level of abstraction as the others -- but I don't have any objection to it at this point. John -- 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.
