Re: [Puppet Users] The handy Grail of Modules Standards
An update on the stdmod works, which are going on slowly, but still moving. We are getting near to define a basic set of names for modules parameters. In particular there's a pull request where various discussions are ongoing on some basic naming patterns: https://github.com/stdmod/puppet-modules/pull/1 the intention is to reach, with this PR, a point where at least the most used and important params names are defined and modules can start to be created / updated based on them. If you don't like the proposed names or have suggestions to make, this is the right moment. Please do that commenting directly the linked pull request. Al -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Mon, Jun 17, 2013 at 1:17 PM, Matthias Saou wrote: > Hi, > > First off... is these some pun I'm not getting, or was it supposed to > be "Holy Grail"? Just wondering :-) > > Also, when I read "Puppet Modules Standard naming conventions", I > thought it was just about module names, but it seems to be about > parameter naming inside all of the module resources. > > After reading the shared Google document, I got reminded a lot of > what I've seen happen with RPM packaging over the years. Lot of > similarities, since both Puppet and RPM are tools which give a lot of > freedom in the way things get implemented. > > Think of GNU/Linux distributions such as Fedora, RHEL, Mandriva, SuSE, > etc. which all use RPM packages as their building blocks : They are not > to be considered compatible for various reasons, yet they could have > been in theory. > RPM based distro storically have diverged mostly for brand and political reason. There are companies that sell support to the users who sponsor the developments. The same RPM was forked countless times with patches incompatible or not upstream. There have been propose in the past to unify the packaging effort but failed http://lists.rpm.org/pipermail/rpm-maint/2008-June/002187.html. RPM is a story in itself, believe me.I know it very well. Puppet as a configuration management it is a completely different story in my opinion. I was possible to do more, and Francesco effort goes in the right direction, in my opinion. Best Regards > > -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
I've made some homework. https://github.com/stdmod/puppet-wget A wget module cloned from the existing openssh one. The git history can show how easy and quick can be to make new modules (well this one is of course a very easy one) with the same parameters patterns. I've also gathered some sample modules which explore different usage cases here: https://github.com/stdmod/puppet-modules/tree/master/modules Feel free, anybody, to add new links to modules done with these (or proposed) patterns... (bin/clone.sh is your friend). (*) We are still talking about a draft... the current ones still need a few basic definitions ... ( package or package_name? file or file_path? or config? or config_path?... still here the current list https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md ) On Friday, August 9, 2013 11:12:36 PM UTC+2, David Schmitt wrote: > > On 2013-08-09 22:56, Alessandro Franceschi wrote: > > > > > > On Friday, August 9, 2013 9:22:54 PM UTC+2, Jakov Sosic wrote: > > > > On 08/08/2013 09:10 PM, Alessandro Franceschi wrote: > > > natural to use two different parameters, like service_ensure and > > > service_enable rather than one like service_status. > > > > Oh, I see. Simpler from the user perspective but more costly from > > performance perspective... > > > > > > > there has been some concern about the amount of parameters or the > > need > > > of some of them, but I think it makes sense to give standard > > names for > > > different possible cases, even if you don't necessarily need to > > use them. > > > > Yeah, that interested me too... Imagine having like 20 modules like > > this > > one included in a node manifest... Wouldn't the compile time explode > > because of all the extra hiera lookups?! :-/ > > > > > > For sure the number of parameters has some impact , as the number of > > resources managed by the module. > > Some Puppet performance experts ( Brice, are you reading :-? ) can > > surely give better ideas of the impact of them when used on scale. > > > > I think it makes sense to make modules that provide some minimal, most > > common, reusability parameters and have the occasion to add features and > > parameters with predictable names and functions. > > This would ease the progressive refinement of a module keeping a > > standard layout. > > > > Really, we should provide and explore more examples, with different > > layouts for different modules structures, and see how this kind of > > parameters fit. > > Actually, I'm not much concerned about the compile-time performance, > given that the alternative are modules that cannot be re-used because > they encode narrow assumptions and do not provide all necessary > extension points. > > > Regards, David > > -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On 2013-08-09 22:56, Alessandro Franceschi wrote: On Friday, August 9, 2013 9:22:54 PM UTC+2, Jakov Sosic wrote: On 08/08/2013 09:10 PM, Alessandro Franceschi wrote: > natural to use two different parameters, like service_ensure and > service_enable rather than one like service_status. Oh, I see. Simpler from the user perspective but more costly from performance perspective... > there has been some concern about the amount of parameters or the need > of some of them, but I think it makes sense to give standard names for > different possible cases, even if you don't necessarily need to use them. Yeah, that interested me too... Imagine having like 20 modules like this one included in a node manifest... Wouldn't the compile time explode because of all the extra hiera lookups?! :-/ For sure the number of parameters has some impact , as the number of resources managed by the module. Some Puppet performance experts ( Brice, are you reading :-? ) can surely give better ideas of the impact of them when used on scale. I think it makes sense to make modules that provide some minimal, most common, reusability parameters and have the occasion to add features and parameters with predictable names and functions. This would ease the progressive refinement of a module keeping a standard layout. Really, we should provide and explore more examples, with different layouts for different modules structures, and see how this kind of parameters fit. Actually, I'm not much concerned about the compile-time performance, given that the alternative are modules that cannot be re-used because they encode narrow assumptions and do not provide all necessary extension points. Regards, David -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Friday, August 9, 2013 9:22:54 PM UTC+2, Jakov Sosic wrote: > > On 08/08/2013 09:10 PM, Alessandro Franceschi wrote: > > natural to use two different parameters, like service_ensure and > > service_enable rather than one like service_status. > > Oh, I see. Simpler from the user perspective but more costly from > performance perspective... > > > > there has been some concern about the amount of parameters or the need > > of some of them, but I think it makes sense to give standard names for > > different possible cases, even if you don't necessarily need to use > them. > > Yeah, that interested me too... Imagine having like 20 modules like this > one included in a node manifest... Wouldn't the compile time explode > because of all the extra hiera lookups?! :-/ > > For sure the number of parameters has some impact , as the number of resources managed by the module. Some Puppet performance experts ( Brice, are you reading :-? ) can surely give better ideas of the impact of them when used on scale. I think it makes sense to make modules that provide some minimal, most common, reusability parameters and have the occasion to add features and parameters with predictable names and functions. This would ease the progressive refinement of a module keeping a standard layout. Really, we should provide and explore more examples, with different layouts for different modules structures, and see how this kind of parameters fit. my2c > > > -- > Jakov Sosic > www.srce.unizg.hr > -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On 08/08/2013 09:10 PM, Alessandro Franceschi wrote: natural to use two different parameters, like service_ensure and service_enable rather than one like service_status. Oh, I see. Simpler from the user perspective but more costly from performance perspective... there has been some concern about the amount of parameters or the need of some of them, but I think it makes sense to give standard names for different possible cases, even if you don't necessarily need to use them. Yeah, that interested me too... Imagine having like 20 modules like this one included in a node manifest... Wouldn't the compile time explode because of all the extra hiera lookups?! :-/ -- Jakov Sosic www.srce.unizg.hr -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Thursday, August 8, 2013 1:45:44 AM UTC+2, Jakov Sosic wrote: > > On 08/06/2013 01:17 AM, Alessandro Franceschi wrote: > > > That's quite nice, I like the reduced verbosity of the code and > > essentiality of an all in one (init.pp) location for resources. > > Yeah, I don't like to partition my module if it's quite simple, as this > one is. > > > For better reusability I'd provide a *_template option to manage the > > templates of all the different files you manage, leaving as the default > > the currently hardcoded ones. > > Yeah, if I decide to publish the module on forge I will for sure add > those parameters too. We need to add Debian support in the house, and > after that I will maybe publish it. > > TSM is a commercial product, we have in-house RPM/DEB packages (because > IBM provided ones are total shit), so without that packages module is > kinda useful. > > This was my attempt to make the 'sample' module for our team to look at > when they code their own. > > > > Also the backup_status and archive_status arguments follow an approach > > that ... erm.. was revisited in the current version of the "ongoing > > standard". > > Can you point me to the revisited approach? I really like the current one > :D > > Well, it makes sense to try to follow, a resource_parameter naming, where possible. So to manage the service status (enable/ensure), probably is more natural to use two different parameters, like service_ensure and service_enable rather than one like service_status. In your case the name of the parameters could be something like backup_service_enable archive_service_ensure (incidentally this would reduce even more the verbosity of your module). The "current" status of the stdmod naming proposal is still : https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md there has been some concern about the amount of parameters or the need of some of them, but I think it makes sense to give standard names for different possible cases, even if you don't necessarily need to use them. > > -- > Jakov Sosic > www.srce.unizg.hr > -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On 08/06/2013 01:17 AM, Alessandro Franceschi wrote: That's quite nice, I like the reduced verbosity of the code and essentiality of an all in one (init.pp) location for resources. Yeah, I don't like to partition my module if it's quite simple, as this one is. For better reusability I'd provide a *_template option to manage the templates of all the different files you manage, leaving as the default the currently hardcoded ones. Yeah, if I decide to publish the module on forge I will for sure add those parameters too. We need to add Debian support in the house, and after that I will maybe publish it. TSM is a commercial product, we have in-house RPM/DEB packages (because IBM provided ones are total shit), so without that packages module is kinda useful. This was my attempt to make the 'sample' module for our team to look at when they code their own. Also the backup_status and archive_status arguments follow an approach that ... erm.. was revisited in the current version of the "ongoing standard". Can you point me to the revisited approach? I really like the current one :D -- Jakov Sosic www.srce.unizg.hr -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
That's quite nice, I like the reduced verbosity of the code and essentiality of an all in one (init.pp) location for resources. For better reusability I'd provide a *_template option to manage the templates of all the different files you manage, leaving as the default the currently hardcoded ones. Also the backup_status and archive_status arguments follow an approach that ... erm.. was revisited in the current version of the "ongoing standard". Discussion about stdmod and naming standards seems faded again, and I've been quite distracted too. I've had recently the need to make a Kibana (3) module and this is the result, for the moment, based on stdmod patterns. https://github.com/example42/puppet-kibana There are quite a lot other sample layouts, for different kind of modules that can be done and shared. Suppose is just a matter to show some works. On Monday, August 5, 2013 11:01:08 PM UTC+2, Jakov Sosic wrote: > > On 06/26/2013 07:27 PM, Alessandro Franceschi wrote: > > Good point. > > In the doc I placed some possible examples on where to assign names, but > > more (or remarks on the ones listed) cases are welcomed. > > (Let me have your email for an invitation to edit) > > > > Btw, comments and access to: > > > https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA > > > is open to everybody, and whoever writes modules should be somehow > > concerned. > > At the moment the discussion seems limited to very few people (even if I > > know various others are silently lurking :-) > > > > The same place of the document is to be considered temporary. > > Let me just hop in and say that I'm really pleased with your stdmod > example, and I already did modify my first module in this way: > > https://code.google.com/p/lutak/source/browse/tsm/manifests/init.pp > > If you think I got something out of the order here, please post critique > ;) > > > > -- > Jakov Sosic > www.srce.unizg.hr > -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On 06/26/2013 07:27 PM, Alessandro Franceschi wrote: Good point. In the doc I placed some possible examples on where to assign names, but more (or remarks on the ones listed) cases are welcomed. (Let me have your email for an invitation to edit) Btw, comments and access to: https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA is open to everybody, and whoever writes modules should be somehow concerned. At the moment the discussion seems limited to very few people (even if I know various others are silently lurking :-) The same place of the document is to be considered temporary. Let me just hop in and say that I'm really pleased with your stdmod example, and I already did modify my first module in this way: https://code.google.com/p/lutak/source/browse/tsm/manifests/init.pp If you think I got something out of the order here, please post critique ;) -- Jakov Sosic www.srce.unizg.hr -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
Hi Ryan Personal and alternative time priorities and availability surely influence the flow of discussion and I definitively have to understand that better in the cases when I've some free time and others not, so sorry everybody for the insistence, and consider the pings about the matter as a way to keep the discussion alive. On Saturday, July 13, 2013 6:04:34 PM UTC+2, Ryan Coleman wrote: > > Hey Al, sorry. I went on holiday and then had to unbury myself. I guess > it's time I get my opinion out there. > > > On Mon, Jul 1, 2013 at 2:33 AM, Alessandro Franceschi > > > wrote: > >> >> >> On Monday, July 1, 2013 5:21:44 AM UTC+2, Ryan Coleman wrote: >>> >>> 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 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 >>> >> >> Agree, and to clarify this even more: >> If module C needs X which is provided by module A and B: >> - A and B should be seamless replaceable (as you said) >> - C should allow easy selection (for the user) of another module that >> provides X >> This second point might look redundant, given the first one, but it might >> be necessary since seamless replacement of modules won't be easy to >> achieve OR a user may want to use a module that does not support the >> standard namings. >> An approach for this second point is the usage of a dependency_class >> parameter (details in the Google Doc), but I'm sure the collective wisdom >> here may find a better solution. >> > > As in, this is the class you're expected to depend on? That's going to be > a little hard to standardize on. Sometimes it's a resource you want, > sometimes a fact, maybe it's multiple classes. > Well, whatever you need from an external module, in this class (for which the module author provides his default) can be replaced by another class, defined and provided by the users, which is supposed to provide the same resources (or declare classes and defines from other modules ). A (not particular elegant) example is this: https://github.com/stdmod/puppet-elasticsearch/blob/master/manifests/dependency.pp which uses legacy resources (git::reposync from a example42 git module you may not use) and creates some opinionated resources like the init script for the elasticsearch service. Another example is this: https://github.com/example42/puppet-graylog2/blob/master/manifests/dependencies.pp where is used a define like mongodb::user which may have different parameters or name or usage patterns in an alternative mongo module actually used by the graylog2 module user. The same would apply for more common cases where in your module you have to use defines apache::vhost or mysql::grant (at least until we don't define a naming standard also for them specifically, but that's another point), if they can stay in a "replaceable" class the module is more reusable and more easily made cross-compatible. I know this is a somehow partial and naif solution, but it's possible with the current language, and I agree that some higher level solutions that may involve code changes in Puppet can and should be seeked. But IMHO one thing doesn't exclude the other. Having some standard parameters names to refer to the name of classes provided by the module than can be replaced directly by the u
Re: [Puppet Users] The handy Grail of Modules Standards
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
Re: [Puppet Users] The handy Grail of Modules Standards
Hey Al, sorry. I went on holiday and then had to unbury myself. I guess it's time I get my opinion out there. On Mon, Jul 1, 2013 at 2:33 AM, Alessandro Franceschi wrote: > > > On Monday, July 1, 2013 5:21:44 AM UTC+2, Ryan Coleman wrote: >> >> 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 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 >> > > Agree, and to clarify this even more: > If module C needs X which is provided by module A and B: > - A and B should be seamless replaceable (as you said) > - C should allow easy selection (for the user) of another module that > provides X > This second point might look redundant, given the first one, but it might > be necessary since seamless replacement of modules won't be easy to > achieve OR a user may want to use a module that does not support the > standard namings. > An approach for this second point is the usage of a dependency_class > parameter (details in the Google Doc), but I'm sure the collective wisdom > here may find a better solution. > As in, this is the class you're expected to depend on? That's going to be a little hard to standardize on. Sometimes it's a resource you want, sometimes a fact, maybe it's multiple classes. > Also this interoperability should be somehow managed at Modulefile level > (and with the puppet module command), so that I can use B even if in the > Modulefile is required A. > This part, which involves changes in Puppet's code, has to be somehow > addressed sooner or later, IMHO. > I couldn't agree with you more here. We've got to allow for dependencies to be interchangeable and I think this is most elegantly solved (for the moment) at the module level, with its metadata and Forge ecosystem. That said, I think that's best left to another thread. > > >> 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. >> > > The idea is that you are not forced to provide all the "proposed" > parameters, but if some of the parameters you provide in your module have > the same function of the ones proposed, you should call them in the > "standard" way. > We might classify parameters in different ways, so that some should be > considered somehow recommended (for a "standard module"), other optional, > and other "extra" or "enhanced", because more specific and exotic > (thinking about the ones related to monitoring/firewalling, for example). > OK. I could get on board with that though I do think that the overall set of parameters needs to be pruned down. Which parameters could be better addressed with module/puppet changes? The dependency_class parameter mentioned above seems like a good example. > > >> Introspectable >> >> - Code follows style guide and other patterns so that contributions are >> more easily made and manag
Re: [Puppet Users] The handy Grail of Modules Standards
On Monday, July 1, 2013 5:21:44 AM UTC+2, Ryan Coleman wrote: > > 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 > > 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 > Agree, and to clarify this even more: If module C needs X which is provided by module A and B: - A and B should be seamless replaceable (as you said) - C should allow easy selection (for the user) of another module that provides X This second point might look redundant, given the first one, but it might be necessary since seamless replacement of modules won't be easy to achieve OR a user may want to use a module that does not support the standard namings. An approach for this second point is the usage of a dependency_class parameter (details in the Google Doc), but I'm sure the collective wisdom here may find a better solution. Also this interoperability should be somehow managed at Modulefile level (and with the puppet module command), so that I can use B even if in the Modulefile is required A. This part, which involves changes in Puppet's code, has to be somehow addressed sooner or later, IMHO. > 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. > The idea is that you are not forced to provide all the "proposed" parameters, but if some of the parameters you provide in your module have the same function of the ones proposed, you should call them in the "standard" way. We might classify parameters in different ways, so that some should be considered somehow recommended (for a "standard module"), other optional, and other "extra" or "enhanced", because more specific and exotic (thinking about the ones related to monitoring/firewalling, for example). > 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) > +1, but with a small note: Even if I think it can be useful to provide some recommended patterns for modules design, this is a somehow more controversial and debatable matter (as the discussion with John in this thread may suggest) so I would not couple it strictly with the discussion about naming standards which it's, imho, more easy to stage and manage. No problems for me in facing all the different problematics behind modules standards, but I'd suggest to make small steps and begin with the easier ones, since putting too many topics in the cauldron and keeping them tied together might make harder any improvement. > 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 we agree on the overall goals. Actually yo
Re: [Puppet Users] The handy Grail of Modules Standards
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 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Wednesday, June 26, 2013 3:37:10 PM UTC+2, jcbollinger wrote:
>
>
>
> On Tuesday, June 25, 2013 4:49:49 PM UTC-5, Alessandro Franceschi wrote:
>>
>>
>>
>> On Tuesday, June 25, 2013 9:16:20 PM UTC+2, jcbollinger wrote:
>>>
>>>
>>> So, here is a version of puppet-stdmod without class parameterization:
>>> https://github.com/jcbollinger/puppet-stdmod .
>>>
>>
>> Ok, this is what I expected.
>>
>
>
> Of course it is. I told you in advance what it was going to be.
>
>
>
>> Thank you for your time.
>> I can definitively argue that this is not fully reusable
>> ("So please show me a reusable module without parameters and without
>> hiera functions inside, as that would not be reusable by whoever does not
>> use Hiera.")
>>
>
>
> And I rejected that standard of reusability, for sound reasons that you
> did not rebut. Since we are closing off that line of discussion, we will
> have to agree to disagree.
>
Actually I DID rebut and anticipated them. That module would not work on at
least ten different Puppet setups where I've worked and Hiera was not used.
But, promise, I won't come back on this, let's happily disagree :-)
>
>> Yes,
>> let's go on.
>> I guess the first steps should be to identify a coherent naming pattern,
>> even before single names and define more precisely what parameters might be
>> recommended, optional, or considered "extensions" .
>>
>>
>
> Before any decision is made on naming patterns -- or at least in
> conjunction with that -- don't you think we should come to grips with the
> patterns of data to which we hope to assign names? The Google doc does
> address that topic, at least implicitly, but I think we should be satisfied
> with the coverage and characterization of the data, else we cannot be
> confident that the chosen names are the most appropriate ones. I will
> devote some attention to that, but I hope I will not be the only one to do
> so.
>
Good point.
In the doc I placed some possible examples on where to assign names, but
more (or remarks on the ones listed) cases are welcomed.
(Let me have your email for an invitation to edit)
Btw, comments and access to:
https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA
is open to everybody, and whoever writes modules should be somehow
concerned.
At the moment the discussion seems limited to very few people (even if I
know various others are silently lurking :-)
The same place of the document is to be considered temporary.
Al
--
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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Tuesday, June 25, 2013 4:49:49 PM UTC-5, Alessandro Franceschi wrote:
>
>
>
> On Tuesday, June 25, 2013 9:16:20 PM UTC+2, jcbollinger wrote:
>>
>>
>> So, here is a version of puppet-stdmod without class parameterization:
>> https://github.com/jcbollinger/puppet-stdmod .
>>
>
> Ok, this is what I expected.
>
Of course it is. I told you in advance what it was going to be.
> Thank you for your time.
> I can definitively argue that this is not fully reusable
> ("So please show me a reusable module without parameters and without
> hiera functions inside, as that would not be reusable by whoever does not
> use Hiera.")
>
And I rejected that standard of reusability, for sound reasons that you did
not rebut. Since we are closing off that line of discussion, we will have
to agree to disagree.
> Yes,
> let's go on.
> I guess the first steps should be to identify a coherent naming pattern,
> even before single names and define more precisely what parameters might be
> recommended, optional, or considered "extensions" .
>
>
Before any decision is made on naming patterns -- or at least in
conjunction with that -- don't you think we should come to grips with the
patterns of data to which we hope to assign names? The Google doc does
address that topic, at least implicitly, but I think we should be satisfied
with the coverage and characterization of the data, else we cannot be
confident that the chosen names are the most appropriate ones. I will
devote some attention to that, but I hope I will not be the only one to do
so.
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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Tuesday, June 25, 2013 11:49:49 PM UTC+2, Alessandro Franceschi wrote:
>
>
>
> On Tuesday, June 25, 2013 9:16:20 PM UTC+2, jcbollinger wrote:
>>
>>
>>
>> On Monday, June 24, 2013 9:12:17 AM UTC-5, Alessandro Franceschi wrote:
>>>
>>>
>>>
>>> On Monday, June 24, 2013 3:57:55 PM UTC+2, jcbollinger wrote:
None of my modules have any parameterized classes, but I am not at
liberty to publish them. I can derive an example from someone else's
module -- maybe yours -- and I will do so if you're actually interested.
However, you have now said at least twice that that's not what you want to
talk about, and I'm not inclined to do the work if you're not interested
in
the result.
>>>
>>> I'm still interested in seeing how this can be done, so any sample code
>>> useful to understand the approach would be extremely welcomed.
>>> Just an example, then we can move on.
>>>
>>>
>> So, here is a version of puppet-stdmod without class parameterization:
>> https://github.com/jcbollinger/puppet-stdmod .
>>
>
> Ok, this is what I expected.
> Thank you for your time.
> I can definitively argue that this is not fully reusable
> ("So please show me a reusable module without parameters and without
> hiera functions inside, as that would not be reusable by whoever does not
> use Hiera.")
> but it's not relevant since with Puppet 3 data bindings we have the best
> of both worlds.
> Personally I see only good reasons to recommend, as patterns for the
> future, modules designed with parametrized classes.
>
>
>> All management capabilities of the original module are retained.
>> Customization data are provided to it via Hiera (which the module calls
>> explicitly), so the most significant change was simply to convert
>> parameters to ordinary variables initialized vie Hiera.
>>
>> The conversion was not entirely mechanical, in that I had to accommodate
>> some Hiera idiosyncrasies -- mainly that it cannot return either undef or
>> (boolean) false. Inasmuch as one would like the parameterized version to
>> be fully compatible with automatic parameter binding, however, I would
>> account at least some of those adaptations as usability enhancements with
>> respect to the parameterized version.
>>
>> I did not convert the tests.
>>
>> Also, I do not specially endorse stdmod's particular design (either
>> version). I would write it at least a bit differently if doing so from
>> scratch, but I think we've agreed to turn the discussion in a different
>> direction.
>>
>>
>> John
>>
>
> Yes,
> let's go on.
> I guess the first steps should be to identify a coherent naming pattern,
> even before single names and define more precisely what parameters might be
> recommended, optional, or considered "extensions" .
>
Talking about naming schemes, here are some possibilities (copied
from:
https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA
) we can discuss and improve.
Given the sample names below, there are at least 2 different approaches
that can be followed, and once defined all the parameters names can somehow
emerge naturally:
1- Place a common suffix for any kind of parameter
2- Place suffixes for some specific params and leave more general names of
general ones
Examples for case 1
ensure
package_name
package_version
service_name
service_ensure
file_path
file_source
file_template
dir_path
dir_source
Examples for case 2
ensure
package
version
service
service_ensure
file_path
source
template
dir_path
dir_source
For both cases extra resources can be referred according to their name and
type of resource, for example: server_package_name, master_file_path,
controller_service_name and things like that.
A general pattern could be:
[name_of_resource]__
- For the “main” resources of a class (main/unique package, main/unique
service, main configuration file...) the name_of_resource is omitted.
- The type_of_resource reflects Puppet types (are “exceptions” like dir_
allowed?)
- The resource_parameter tends to map to a typical Puppet resource
parameter (exceptions like template, version, options?)
--
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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Tuesday, June 25, 2013 10:10:13 PM UTC+2, Ygor wrote: > > I have been watching this thread grow and metastasize and I would like to > offer my opinions: > > "The wonderful thing about standards is that there are so many of them to > choose from." Grace Hopper (maybe) > > There are at least two very different directions to approach this from, > IMHO. > > The first is from the idea to create a universally useable module that can > be dropped into any puppet master and run without modification. This seems > to me to be the approach of Example-42. > The other approach is to provide a set of common sense, best-practice > guidelines for folks to use to "grow" their own modules for their own > specific needs. > > I think both are necessary and valuable. > > My grumble about the Example-42-Swiss-Army-Knife approach is that I would > like to know what is absolutely necessary and what is optional. I do not > want to implement the equivalent of the Sears Craftsman Gazillon Piece Tool > Warehouse when all I need is one lousy Phillip's screwdriver. Well the idea is that in the Fat Warehouse you pick the screwdriver you need, the others are there, at disposal, mostly harmless. > I have dug thru some of the Example 42 modules and I have learned more > than a few nifty ways of getting things done, but I am working in a > one-operating-system environment (Red Hat) and I do not need all the extra > code to cover the other OS's. Others will. The first step for modules' reusability is support of multiple OS. Note, IMHO a reusable module is not always the right choice: slim and essential code for very specific and internally standardised setups can be preferred at times. > Other grumbles (not only about Example 42) include sparse documentation > and examples: If you are going to define a pile of parameters, it would be > very helpful to include examples to show how to use them. Very few > published modules provide enough detail to make me happy. That's another good reason to standardize the names of common sense parameters, that can therefore be better documented and explained. > > The old saying is "There's more than one way to skin a cat." (My apologies > to all ailurophiles out there, of which I am one) > Same thing here. Puppet is a potentially powerful framework for system > configuration and management. If you are sloppy about how you use it, you > can booger up your systems big-time and lose important data. > > Exactly how to do it all is not as important (IMHO) as learning right and > wrong ways to do individual tasks. It is then up to the individual DevOp to > tailor the pieces to fit their particular needs and environment. Yes, but when this tailoring becomes "take existing modules and modify or write them from scratch " you end up seeing dozens of randomly documented and designed Mysql modules, that can be used in different ways and may have weird cross dependencies. That's why starting for some naming standards helps. That's also why I personally think that some common modules like apache, mysql, nginx, postgres or other that are frequently used by third modules should have explicit and dedicated standard parameters for the typical defines they provide. my2c al -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Tuesday, June 25, 2013 9:16:20 PM UTC+2, jcbollinger wrote:
>
>
>
> On Monday, June 24, 2013 9:12:17 AM UTC-5, Alessandro Franceschi wrote:
>>
>>
>>
>> On Monday, June 24, 2013 3:57:55 PM UTC+2, jcbollinger wrote:
>>>
>>>
>>> None of my modules have any parameterized classes, but I am not at
>>> liberty to publish them. I can derive an example from someone else's
>>> module -- maybe yours -- and I will do so if you're actually interested.
>>> However, you have now said at least twice that that's not what you want to
>>> talk about, and I'm not inclined to do the work if you're not interested in
>>> the result.
>>>
>>
>> I'm still interested in seeing how this can be done, so any sample code
>> useful to understand the approach would be extremely welcomed.
>> Just an example, then we can move on.
>>
>>
> So, here is a version of puppet-stdmod without class parameterization:
> https://github.com/jcbollinger/puppet-stdmod .
>
Ok, this is what I expected.
Thank you for your time.
I can definitively argue that this is not fully reusable
("So please show me a reusable module without parameters and without
hiera functions inside, as that would not be reusable by whoever does not
use Hiera.")
but it's not relevant since with Puppet 3 data bindings we have the best of
both worlds.
Personally I see only good reasons to recommend, as patterns for the
future, modules designed with parametrized classes.
> All management capabilities of the original module are retained.
> Customization data are provided to it via Hiera (which the module calls
> explicitly), so the most significant change was simply to convert
> parameters to ordinary variables initialized vie Hiera.
>
> The conversion was not entirely mechanical, in that I had to accommodate
> some Hiera idiosyncrasies -- mainly that it cannot return either undef or
> (boolean) false. Inasmuch as one would like the parameterized version to
> be fully compatible with automatic parameter binding, however, I would
> account at least some of those adaptations as usability enhancements with
> respect to the parameterized version.
>
> I did not convert the tests.
>
> Also, I do not specially endorse stdmod's particular design (either
> version). I would write it at least a bit differently if doing so from
> scratch, but I think we've agreed to turn the discussion in a different
> direction.
>
>
> John
>
Yes,
let's go on.
I guess the first steps should be to identify a coherent naming pattern,
even before single names and define more precisely what parameters might be
recommended, optional, or considered "extensions" .
The google doc is always open to scribble some ideas and proposals.
Al
--
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.
Re: [Puppet Users] The handy Grail of Modules Standards
I have been watching this thread grow and metastasize and I would like to offer my opinions: "The wonderful thing about standards is that there are so many of them to choose from." Grace Hopper (maybe) There are at least two very different directions to approach this from, IMHO. The first is from the idea to create a universally useable module that can be dropped into any puppet master and run without modification. This seems to me to be the approach of Example-42. The other approach is to provide a set of common sense, best-practice guidelines for folks to use to "grow" their own modules for their own specific needs. I think both are necessary and valuable. My grumble about the Example-42-Swiss-Army-Knife approach is that I would like to know what is absolutely necessary and what is optional. I do not want to implement the equivalent of the Sears Craftsman Gazillon Piece Tool Warehouse when all I need is one lousy Phillip's screwdriver. I have dug thru some of the Example 42 modules and I have learned more than a few nifty ways of getting things done, but I am working in a one-operating-system environment (Red Hat) and I do not need all the extra code to cover the other OS's. Other grumbles (not only about Example 42) include sparse documentation and examples: If you are going to define a pile of parameters, it would be very helpful to include examples to show how to use them. Very few published modules provide enough detail to make me happy. The old saying is "There's more than one way to skin a cat." (My apologies to all ailurophiles out there, of which I am one) Same thing here. Puppet is a potentially powerful framework for system configuration and management. If you are sloppy about how you use it, you can booger up your systems big-time and lose important data. Exactly how to do it all is not as important (IMHO) as learning right and wrong ways to do individual tasks. It is then up to the individual DevOp to tailor the pieces to fit their particular needs and environment. And to use the closing of Dennis Miller, "...of course, that's just my opinion . I could be wrong." “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Monday, June 24, 2013 9:12:17 AM UTC-5, Alessandro Franceschi wrote: > > > > On Monday, June 24, 2013 3:57:55 PM UTC+2, jcbollinger wrote: >> >> >> None of my modules have any parameterized classes, but I am not at >> liberty to publish them. I can derive an example from someone else's >> module -- maybe yours -- and I will do so if you're actually interested. >> However, you have now said at least twice that that's not what you want to >> talk about, and I'm not inclined to do the work if you're not interested in >> the result. >> > > I'm still interested in seeing how this can be done, so any sample code > useful to understand the approach would be extremely welcomed. > Just an example, then we can move on. > > So, here is a version of puppet-stdmod without class parameterization: https://github.com/jcbollinger/puppet-stdmod . All management capabilities of the original module are retained. Customization data are provided to it via Hiera (which the module calls explicitly), so the most significant change was simply to convert parameters to ordinary variables initialized vie Hiera. The conversion was not entirely mechanical, in that I had to accommodate some Hiera idiosyncrasies -- mainly that it cannot return either undef or (boolean) false. Inasmuch as one would like the parameterized version to be fully compatible with automatic parameter binding, however, I would account at least some of those adaptations as usability enhancements with respect to the parameterized version. I did not convert the tests. Also, I do not specially endorse stdmod's particular design (either version). I would write it at least a bit differently if doing so from scratch, but I think we've agreed to turn the discussion in a different direction. 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Monday, June 24, 2013 3:57:55 PM UTC+2, jcbollinger wrote:
>
>
>
> On Friday, June 21, 2013 6:21:22 PM UTC-5, Alessandro Franceschi wrote:
>>
>>
>>
>> On Friday, June 21, 2013 5:05:20 PM UTC+2, jcbollinger wrote:
>>>
>>> Anything you can configure with class parameters, you can configure
>>> without them via external data. Generally speaking, I would turn to hiera
>>> for that. If you want an ENC that surpasses hiera's built-in capabilities,
>>> then it can be written in the form of a custom hiera back-end.
>>>
>>> On the other hand, if your criterion for a module being "reusable" is
>>> that it can be used in every way exactly as a module based on parameterized
>>> classes can be used, then the question is rigged.
>>>
>>> That hiera was not built-in to Puppet 2 does not alter my evaluation
>>> here. It is readily available and widely used with that series. I have
>>> always held that parameterized classes were not safe to use in Puppet 2
>>> anyway, so if the objective is modules that are reusable in Puppet 2 then I
>>> would go beyond "parameterization is not required" to "parameterization of
>>> API classes is forbidden". That leaves you with dynamic scoping and
>>> extlookup() as your only built-in alternatives, and however suitable they
>>> may be (or not) for Puppet 2, they are not suitable for Puppet
>>> If the objective is for modules to be written so as to be usable in both
>>> Puppet 2 and Puppet 3, then I think Hiera is the only viable alternative.
>>> Classes belonging to module APIs must not be declared via the parameterized
>>> style, and though avoiding that in Puppet 2 could be supported by using
>>> hiera() calls for parameter default values, writing API classes that way
>>> produces (i) worse compilation performance in Puppet 3, and (ii) the
>>> opportunity for users to shoot themselves in the foot.
>>>
>>
>> Still words and no samples John.
>>
>>
>
> None of my modules have any parameterized classes, but I am not at liberty
> to publish them. I can derive an example from someone else's module --
> maybe yours -- and I will do so if you're actually interested. However,
> you have now said at least twice that that's not what you want to talk
> about, and I'm not inclined to do the work if you're not interested in the
> result.
>
I'm still interested in seeing how this can be done, so any sample code
useful to understand the approach would be extremely welcomed.
Just an example, then we can move on.
I'm not interested in sticking the discussion on that, also because I feel
like we might have found the right "communication frequency"
>
> Either way, whether such modules are common is altogether beside the (my)
> point, which is about whether conventions such as you wish to develop and
> promote should *require* modules' API classes to be parameterized. I
> will oppose that aspect of any such effort.
>
> The more fundamental idea of a common mapping of data and data types to
> names (i.e. a data "ontology"), on the other hand, is an outstanding idea.
> If the discussion is at that level then it will certainly keep my interest,
> and it may attract my active participation.
>
Good.
Then consider that all the name for "parameters" in:
https://docs.google.com/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA/edit?usp=sharing
may either refer to class' parameters or to hiera variables.
For example a parameter "ensure" on the module apache, would map to
hiera('apache::ensure').
What of those parameters/hiera variables could be considered useful enough
to be recommended?
What would be their names?
--
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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Friday, June 21, 2013 6:21:22 PM UTC-5, Alessandro Franceschi wrote: > > > > On Friday, June 21, 2013 5:05:20 PM UTC+2, jcbollinger wrote: >> >> Anything you can configure with class parameters, you can configure >> without them via external data. Generally speaking, I would turn to hiera >> for that. If you want an ENC that surpasses hiera's built-in capabilities, >> then it can be written in the form of a custom hiera back-end. >> >> On the other hand, if your criterion for a module being "reusable" is >> that it can be used in every way exactly as a module based on parameterized >> classes can be used, then the question is rigged. >> >> That hiera was not built-in to Puppet 2 does not alter my evaluation >> here. It is readily available and widely used with that series. I have >> always held that parameterized classes were not safe to use in Puppet 2 >> anyway, so if the objective is modules that are reusable in Puppet 2 then I >> would go beyond "parameterization is not required" to "parameterization of >> API classes is forbidden". That leaves you with dynamic scoping and >> extlookup() as your only built-in alternatives, and however suitable they >> may be (or not) for Puppet 2, they are not suitable for Puppet >> If the objective is for modules to be written so as to be usable in both >> Puppet 2 and Puppet 3, then I think Hiera is the only viable alternative. >> Classes belonging to module APIs must not be declared via the parameterized >> style, and though avoiding that in Puppet 2 could be supported by using >> hiera() calls for parameter default values, writing API classes that way >> produces (i) worse compilation performance in Puppet 3, and (ii) the >> opportunity for users to shoot themselves in the foot. >> > > Still words and no samples John. > > None of my modules have any parameterized classes, but I am not at liberty to publish them. I can derive an example from someone else's module -- maybe yours -- and I will do so if you're actually interested. However, you have now said at least twice that that's not what you want to talk about, and I'm not inclined to do the work if you're not interested in the result. Either way, whether such modules are common is altogether beside the (my) point, which is about whether conventions such as you wish to develop and promote should *require* modules' API classes to be parameterized. I will oppose that aspect of any such effort. The more fundamental idea of a common mapping of data and data types to names (i.e. a data "ontology"), on the other hand, is an outstanding idea. If the discussion is at that level then it will certainly keep my interest, and it may attract my active participation. 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Saturday, June 22, 2013 11:47:13 AM UTC+2, Wolf Noble wrote: > > > I'd like to say I really like the intent behind this. > > Yes, a name is important. So is continuity. I believe the underlying goal > is to provide a collection of reference material. Once the skeleton of this > material is generally agreed upon, it can be used as guidelines to the > community for how to implement a common set of functionality with > performance, and the greatest quantity of interoperability in mind. > > How is this a bad thing? > > The demonstrated example shows plenty of well thought out functionality. > How might we better implement these functional knobs and levers? > Yes, that's the kind of things I'd like to discuss. > > Lets go beyond the fact that the only reason we call knobs, switches, and > levers what we do is that communally we agreed that this long-ish thing > protruding from this surface over here should be called a lever, that this > definitive state toggle be called a switch, and this round, grabbable > twisty thing here should be called a knob. Names are important, but not > just because they're names, they're icons of functionality. > > Consistently referring to a lever as a lever provides more intuitive > context, but doesn't change how it operates. Does it do the same thing if > you call it a widget? Sure! Does it help with the goal of communally > establishing conventions of grounding and interoperability? Not so much. > > So, on the one hand, no, this conversation is not purely about naming > conventions. On the other, I don't think that's the point to focus on. > > I can absolutely see the value in a few sets of versioned > "interoperability reference" modules, which provide one a good working > model of how to provide specific bits of functionality in as flexible a > manner as necessary. > > There are several different good module paradigms out there. I feel that > fragmentation of design and implementation hinders the community more than > a little bit. It confuses it, at the very least. > > I do not believe a 'one-size-fits-all' paradigm would do us all that much > good here either. You'd likely always be one side or the other of too much > scaffolding for simple modules, and not enough flexibility for complicated > ones. > Agree. > > I believe this means a few levels of module complexity would need to be > modeled. Then the transitions between those states would be more > straightforward. Someone could expand the functionality of your module with > greater ease and consistency. > Totally agree. > > I would love to see other examples which provide similar levels of > implemented functionality. > Actually it would be interesting, and actually is something that is definitively planned, to explore, different sample modules for different kind of applications: for example Java/Rails apps, or more complex cases, where you need defines but maybe also types and providers, also to validate and test the naming and functional choices. > (... (:(: and then the bikeshedding and performance holy wars can really > get going :):) ...) > > What other good ways are there to easily write unit tests to validate the > different behaviors of a module without parameters? > Facts? > Limited scope/functionality subclasses? > I still can't figure out how to make a reusable module without parameters and without explicit hiera calls inside. I'd really be interested in seeing an example. > This is a very exciting subject of conversation. I am thankful to everyone > participating in it for their thoughts and contributions. > I'm looking forward for your suggestions on: https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA al -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
I'd like to say I really like the intent behind this. Yes, a name is important. So is continuity. I believe the underlying goal is to provide a collection of reference material. Once the skeleton of this material is generally agreed upon, it can be used as guidelines to the community for how to implement a common set of functionality with performance, and the greatest quantity of interoperability in mind. How is this a bad thing? The demonstrated example shows plenty of well thought out functionality. How might we better implement these functional knobs and levers? Lets go beyond the fact that the only reason we call knobs, switches, and levers what we do is that communally we agreed that this long-ish thing protruding from this surface over here should be called a lever, that this definitive state toggle be called a switch, and this round, grabbable twisty thing here should be called a knob. Names are important, but not just because they're names, they're icons of functionality. Consistently referring to a lever as a lever provides more intuitive context, but doesn't change how it operates. Does it do the same thing if you call it a widget? Sure! Does it help with the goal of communally establishing conventions of grounding and interoperability? Not so much. So, on the one hand, no, this conversation is not purely about naming conventions. On the other, I don't think that's the point to focus on. I can absolutely see the value in a few sets of versioned "interoperability reference" modules, which provide one a good working model of how to provide specific bits of functionality in as flexible a manner as necessary. There are several different good module paradigms out there. I feel that fragmentation of design and implementation hinders the community more than a little bit. It confuses it, at the very least. I do not believe a 'one-size-fits-all' paradigm would do us all that much good here either. You'd likely always be one side or the other of too much scaffolding for simple modules, and not enough flexibility for complicated ones. I believe this means a few levels of module complexity would need to be modeled. Then the transitions between those states would be more straightforward. Someone could expand the functionality of your module with greater ease and consistency. I would love to see other examples which provide similar levels of implemented functionality. (... (:(: and then the bikeshedding and performance holy wars can really get going :):) ...) What other good ways are there to easily write unit tests to validate the different behaviors of a module without parameters? Facts? Limited scope/functionality subclasses? This is a very exciting subject of conversation. I am thankful to everyone participating in it for their thoughts and contributions. -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Friday, June 21, 2013 5:05:20 PM UTC+2, jcbollinger wrote: > > > > On Thursday, June 20, 2013 10:14:09 AM UTC-5, Alessandro Franceschi wrote: >> >> >> >> On Thursday, June 20, 2013 4:12:46 PM UTC+2, jcbollinger wrote: >>> >>> >>> >>> On Wednesday, June 19, 2013 5:34:58 PM UTC-5, Alessandro Franceschi >>> wrote: >>> >>> *A really reusable module HAS to be parametrized*. >>> >>> >>> Utter hogwash. >>> >> >> Lol. Show me a real example of a reusable module without parametrized >> classes that at least manages a typical package/service/configuration file >> scenario. >> Give me proofs, not words that I have to search on a dictionary. >> >> > > > Anything you can configure with class parameters, you can configure > without them via external data. Generally speaking, I would turn to hiera > for that. If you want an ENC that surpasses hiera's built-in capabilities, > then it can be written in the form of a custom hiera back-end. > > On the other hand, if your criterion for a module being "reusable" is that > it can be used in every way exactly as a module based on parameterized > classes can be used, then the question is rigged. > > That hiera was not built-in to Puppet 2 does not alter my evaluation > here. It is readily available and widely used with that series. I have > always held that parameterized classes were not safe to use in Puppet 2 > anyway, so if the objective is modules that are reusable in Puppet 2 then I > would go beyond "parameterization is not required" to "parameterization of > API classes is forbidden". That leaves you with dynamic scoping and > extlookup() as your only built-in alternatives, and however suitable they > may be (or not) for Puppet 2, they are not suitable for Puppet > If the objective is for modules to be written so as to be usable in both > Puppet 2 and Puppet 3, then I think Hiera is the only viable alternative. > Classes belonging to module APIs must not be declared via the parameterized > style, and though avoiding that in Puppet 2 could be supported by using > hiera() calls for parameter default values, writing API classes that way > produces (i) worse compilation performance in Puppet 3, and (ii) the > opportunity for users to shoot themselves in the foot. > Still words and no samples John. I show you again this one, then. https://github.com/example42/puppet-stdmod it does what we want. Automatic Hiera lookups if you have Puppet3, and I hope data bindings are here to stay. or parametrized classes declarations, which are finally getting some respect also from ENCs. You can use it how you want. And if you don't like how the module is done, as I presume, you can do a different version, like this: https://github.com/example42/puppet-stdmodalt or whatever other better layout you may want to produce. They are based on parametrized classes, incidentally. I'm still not able to make a truly reusable module in other ways. (And still don't see them around). But this is not the point. Are the parameters / hiera variables suggested useful? Can some of them be considered useful for the module's reusability? Which ones are good enough to be considered obvious and a logic? Which ones make sense enough to have a common name and be suggested as standard? Which other ones can be suggested? Now, really, I would prefer to discuss about that with* you,* if you want and most of all *eveybody * *t*hinks this might a good thing for the evolution of the modules' ecosystem in the next years. (Hello PuppetLabs?) -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Thursday, June 20, 2013 10:14:09 AM UTC-5, Alessandro Franceschi wrote: > > > > On Thursday, June 20, 2013 4:12:46 PM UTC+2, jcbollinger wrote: >> >> >> >> On Wednesday, June 19, 2013 5:34:58 PM UTC-5, Alessandro Franceschi wrote: >> >> >>> *A really reusable module HAS to be parametrized*. >>> >> >> >> Utter hogwash. >> > > Lol. Show me a real example of a reusable module without parametrized > classes that at least manages a typical package/service/configuration file > scenario. > Give me proofs, not words that I have to search on a dictionary. > > Anything you can configure with class parameters, you can configure without them via external data. Generally speaking, I would turn to hiera for that. If you want an ENC that surpasses hiera's built-in capabilities, then it can be written in the form of a custom hiera back-end. On the other hand, if your criterion for a module being "reusable" is that it can be used in every way exactly as a module based on parameterized classes can be used, then the question is rigged. That hiera was not built-in to Puppet 2 does not alter my evaluation here. It is readily available and widely used with that series. I have always held that parameterized classes were not safe to use in Puppet 2 anyway, so if the objective is modules that are reusable in Puppet 2 then I would go beyond "parameterization is not required" to "parameterization of API classes is forbidden". That leaves you with dynamic scoping and extlookup() as your only built-in alternatives, and however suitable they may be (or not) for Puppet 2, they are not suitable for Puppet 3. If the objective is for modules to be written so as to be usable in both Puppet 2 and Puppet 3, then I think Hiera is the only viable alternative. Classes belonging to module APIs must not be declared via the parameterized style, and though avoiding that in Puppet 2 could be supported by using hiera() calls for parameter default values, writing API classes that way produces (i) worse compilation performance in Puppet 3, and (ii) the opportunity for users to shoot themselves in the foot. 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Thursday, June 20, 2013 1:07:22 PM UTC-5, David Schmitt wrote: > > On 2013-06-20 16:12, jcbollinger wrote: > > I just have low regard for software that > > doesn't yet exist. I do not find the potential for nebulous future > > software a persuasive argument for adopting anything. > > You might want to check out the significant amount of modules available > at http://github.com/Example42 that are the source of these naming > conventions. > > I am aware of them, and of their connection to this discussion, but they are nothing to do with my quoted comment. A check of the context will show that I was talking about this: > but I see various other clear benefits, in the mid term: > - The possibility to have an unified approach to smoke testing of common features > - The possibility to have web front-ends and ENC that leverage on the standardized parameters 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On 2013-06-20 16:12, jcbollinger wrote: I just have low regard for software that doesn't yet exist. I do not find the potential for nebulous future software a persuasive argument for adopting anything. You might want to check out the significant amount of modules available at http://github.com/Example42 that are the source of these naming conventions. Regards, David -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Thursday, June 20, 2013 4:12:46 PM UTC+2, jcbollinger wrote: > > > > On Wednesday, June 19, 2013 5:34:58 PM UTC-5, Alessandro Franceschi wrote: >> >> >> >> On Wednesday, June 19, 2013 5:03:41 PM UTC+2, jcbollinger wrote: >>> >>> >>> Call me "experienced", "jaded", or even "cynical", but I know of too >>> many instances of vaporware to be swayed by promises of software that >>> hasn't yet been written. >>> >> >> I just call you cynical. We can't do anything if we don't try to do it. >> >> > > By all means, do. If you are somehow getting the impression that I object > to the project then I apologize. Indeed, I encourage you to proceed, and I > wish you well. I just have low regard for software that doesn't yet > exist. I do not find the potential for nebulous future software a > persuasive argument for adopting anything. > > What I actually object to is misrepresentation -- even though accidental > -- of the nature and scope of the project. It is NOT restricted to > choosing names. > > Secondarily, I object to positioning the effort as a standardization > project, and I advise you to position it differently. Names and labels are > meaningful. How the project proceeds, who participates, what they propose, > and all manner of intangibles will be influenced by your decisions in this > regard. Frankly, I am inclined to resist a "standardization" effort from > any random third party, but I have no reason whatever to oppose anyone > drafting a set of conventions or best practices. After they have been > tested in the field will be a suitable time to consider standardization or > endorsement. > > > >> *A really reusable module HAS to be parametrized*. >> > > > Utter hogwash. > Lol. Show me a real example of a reusable module without parametrized classes that at least manages a typical package/service/configuration file scenario. Give me proofs, not words that I have to search on a dictionary. > > > >> Take note, I can repeat and argument that anytime. >> > > > Then no doubt we'll be hearing from each other on this again. > > > >> Parameters are the API of a module, the interface you can interact with >> it without touching it. >> If you don't use parameters either you are forcing inside the module >> behaviours that can't be changed by users or you are forcing a specific way >> to obtain the data that affects the modules behaviour and this inherently >> makes it not reusable for people who provide data in other ways. >> > > > The data consumed by a module and the labels by which they are identified > are certainly parts of a module's API, but it is by no means necessary to > express those or interact with them in the form of class parameters. You > cannot safely use parameterized-style class declarations (as opposed to > class *definitions*) of any API class, especially in or with modules > intended to be interoperable. That makes parameterization largely moot as > far as reusability goes. If people want to parameterize their classes then > I have no special reason to object. I do object, however, to the premise > that doing so usefully improves reusability or interoperability, and > therefore I object to any proposal that expressly calls for classes to be > parameterized. > > As long as we're talking about standards, Hiera is Puppet's de facto > standard interface to external data. It is usually expected that proposed > standards will build on other, existing standards, whether de facto or > formal. > Sadly, Hiera is not the only de facto standard interface to Puppet's external data. Variables set via an ENC are another widely used "standard". Also I'd say that Hiera is standard with Puppet 3, not with earlier versions. So please show me a reusable module without parameters and without hiera functions inside, as that would not be reusable by whoever does not use Hiera. > I think your proposal would be stronger if it truly did focus on the data > that might need to be supported by modules and the names / labels / keys by > which they are identified. If you choose a namespace-based system then you > can align it to be consistent with class parameterization and automated > parameter binding, yet not dependent on those. I know you want more, but > you should consider making a separate effort of the rest. > I've no problems in concentrating in naming without "forcing" the usage of parametrized classes, but still have to figure out HOW to manage injection of external data to the module without using parameters (and without using hiera calls or references to arbitrary fully qualified variables names). Curiously one of my efforts in the past has been exactly towards this direction, so I have actually a solution for that, but it still requires a parametrized class, even if you can use it with a simple include. > >> >>> >>> Most importantly, however, my central objection here is that a proposal >>> that purports to be exclusively about
Re: [Puppet Users] The handy Grail of Modules Standards
On Wednesday, June 19, 2013 5:34:58 PM UTC-5, Alessandro Franceschi wrote: > > > > On Wednesday, June 19, 2013 5:03:41 PM UTC+2, jcbollinger wrote: >> >> >> Call me "experienced", "jaded", or even "cynical", but I know of too many >> instances of vaporware to be swayed by promises of software that hasn't yet >> been written. >> > > I just call you cynical. We can't do anything if we don't try to do it. > > By all means, do. If you are somehow getting the impression that I object to the project then I apologize. Indeed, I encourage you to proceed, and I wish you well. I just have low regard for software that doesn't yet exist. I do not find the potential for nebulous future software a persuasive argument for adopting anything. What I actually object to is misrepresentation -- even though accidental -- of the nature and scope of the project. It is NOT restricted to choosing names. Secondarily, I object to positioning the effort as a standardization project, and I advise you to position it differently. Names and labels are meaningful. How the project proceeds, who participates, what they propose, and all manner of intangibles will be influenced by your decisions in this regard. Frankly, I am inclined to resist a "standardization" effort from any random third party, but I have no reason whatever to oppose anyone drafting a set of conventions or best practices. After they have been tested in the field will be a suitable time to consider standardization or endorsement. > *A really reusable module HAS to be parametrized*. > Utter hogwash. > Take note, I can repeat and argument that anytime. > Then no doubt we'll be hearing from each other on this again. > Parameters are the API of a module, the interface you can interact with it > without touching it. > If you don't use parameters either you are forcing inside the module > behaviours that can't be changed by users or you are forcing a specific way > to obtain the data that affects the modules behaviour and this inherently > makes it not reusable for people who provide data in other ways. > The data consumed by a module and the labels by which they are identified are certainly parts of a module's API, but it is by no means necessary to express those or interact with them in the form of class parameters. You cannot safely use parameterized-style class declarations (as opposed to class *definitions*) of any API class, especially in or with modules intended to be interoperable. That makes parameterization largely moot as far as reusability goes. If people want to parameterize their classes then I have no special reason to object. I do object, however, to the premise that doing so usefully improves reusability or interoperability, and therefore I object to any proposal that expressly calls for classes to be parameterized. As long as we're talking about standards, Hiera is Puppet's de facto standard interface to external data. It is usually expected that proposed standards will build on other, existing standards, whether de facto or formal. I think your proposal would be stronger if it truly did focus on the data that might need to be supported by modules and the names / labels / keys by which they are identified. If you choose a namespace-based system then you can align it to be consistent with class parameterization and automated parameter binding, yet not dependent on those. I know you want more, but you should consider making a separate effort of the rest. > >> >> Most importantly, however, my central objection here is that a proposal >> that purports to be exclusively about naming parameters in fact has any >> implications at all for module organization and style. >> > > Ok, it's not a proposal that purports to be exclusively about naming > parameters: the usage of specific parameters involve patterns that enhance > modules' reusability and interoperability. > The sample module code definitively exposes design patterns with modules > (and it demonstrates that you can follow different patterns to achieve the > same behaviour. > > Reading it again this is not so clear in the first post here, but it's > widely expressed in the linked pages. > So, sorry, now let's move a step further, let's talk, if you want, about > how to make that paper/draft/proposal better. > And if you think that such a thing should not even be discussed, well, ok, > I'll accept that and discuss it with who is interested in it. > > I think it would be better if it actually were narrowed in scope to identifying patterns in the data that modules consume, and choosing naming conventions for those data. Better, and also easier to reach consensus on. Include some comments about namespacing, especially in conjunction with accessing data via Hiera. These issues are separate from and more fundamental than class parameterization or module organization. They will, however, influence anyone who cho
Re: [Puppet Users] The handy Grail of Modules Standards
On 20.06.2013 00:34, Alessandro Franceschi wrote: Having a curated repository of interoperable modules without a minimum set of shared parameters would be a great drawback and a major lost occasion. Yes. _A really reusable module HAS to be parametrized_. Yes. Somehow it also seems that some other people are doing the same with them, given some figures from GitHub and the fact that about 100 different committers have improved or patched them. Yes. One of the reasons why I'm basically considering to thrash all this "legacy" work and trying to promote and embrace wider standards is that I definitively think that they can give great benefits to Puppet's modules ecosystem. Yes. Still this idea is not only mine, I've talked and shared it with various other Puppetteers (some of them started to make modules even before me or you even knew what Puppet was) and the consensus is wide enough to make me think that even without an explicit support from PuppetLabs, a robust, coherent, shared and single repository of Puppet modules made by (some) community members can be done and can work well. Yes. Regards, David -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Wednesday, June 19, 2013 5:03:41 PM UTC+2, jcbollinger wrote: > > > > On Tuesday, June 18, 2013 1:19:32 PM UTC-5, Alessandro Franceschi wrote: >> >> Some personal notes among the lines... >> >> On Tuesday, June 18, 2013 6:35:18 PM UTC+2, Ken Barber wrote: >>> >>> > Although I agree that to be reusable, modules need to provide certain >>> types >>> > of levers, knobs, and switches, as appropriate for their scopes, I >>> think the >>> > case is weak for those controls needing to be called by the same >>> names. At >>> > best, naming conventions for such things might improve ease of (re)use >>> for >>> > some people, but the key factor for reusability is not the names of >>> the >>> > controls so much as their presence in the first place. >>> >> >> Well on this I definitively do not agree :-) >> 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) >> >> Given these points, I think that some of the parameters names proposed in >> the draft actually DO inherently enhance a module reusability: >> For point 2: source, template, options (with might make useless almost >> any additional application specific configuration parameter), dir_source >> (and dir_* ) >> For point 3: status, autorestart (poor name), audits, noops >> For point 4: package, service, file_path, dir_path >> For point 5: my_class resources_hash >> >> But maybe we have different semantic nuances for the term "modules' >> reusability". >> > > > Evidently so. For the most part, what you said does not conflict with what > I said; you were just more specific. Where we differ is that I am > distinguishing "reusability" from *ease* of reuse. I agree that all of > your items 1 - 6 are factors that improve modules' reusability. I assert, > however, that the names by which those particular knobs are referenced do > not constitute essential reusability factors, but rather ease of use > factors. > Here I really don't follow you: if you agree that the above points improves modules' reusability, how can you say that defining naming standards for parameters that empower those points just enhance ease of use and not the same reusability of a module that implements them? > > Basically, I am drawing the line at having to modify the code to use a > third-party module. The module is "reusable" if I do not have to modify > it, even if I have to study it to determine how to use it. It is easy to > use if it presents a coherent, intuitive external interface. Almost all > naming considerations fall into the latter category. > Well at least we agree on the definition of a reusable module. > > Moreover, any ease of use advantage of such a convention is limited to > those users who buy in to the convention. Such buy-in is unlikely to arise > from a standard-setting effort alone. > > >> >> I agree that the interoperability part is not fully dependent on naming >> standards. >> Aa a partial solution for this I have thought about the usage of a >> "dependency_class" to contain in a single, replaceable, class all the >> external dependencies, and eventually tweaking the Modulefile and the >> puppet module command to manage soft-dependencies and reduce conflicts >> modules Forge modules (more details on this on the blog post linked before). >> I don't see it as a perfect solution but that's something that can be >> done now (without extra code if not for the Forge integration) and very >> quickly. >> > > > I have some issues with that approach, but I'm going to disregard them for > now because that topic is largely beyond the stated scope of the naming > conventions and convention-drafting effort we are discussing. > > > >> >>> I think being able to use another class in a drop-in way is not the >>> value I see in parameter naming 'recommendations'. I personal see >>> value in the ease of use more than anything, if parameters are >>> similarly named between classes, when you go to use them you don't >>> have to interrupt, double check with the docs what this class/define >>> uses, then modify your parameter name accordingly. Its a reduction in >>> surprise if anything. An example would be the 'package' parameter, >>> versus 'packages' ... if I did
Re: [Puppet Users] The handy Grail of Modules Standards
On Tuesday, June 18, 2013 1:19:32 PM UTC-5, Alessandro Franceschi wrote: > > Some personal notes among the lines... > > On Tuesday, June 18, 2013 6:35:18 PM UTC+2, Ken Barber wrote: >> >> > Although I agree that to be reusable, modules need to provide certain >> types >> > of levers, knobs, and switches, as appropriate for their scopes, I >> think the >> > case is weak for those controls needing to be called by the same names. >> At >> > best, naming conventions for such things might improve ease of (re)use >> for >> > some people, but the key factor for reusability is not the names of the >> > controls so much as their presence in the first place. >> > > Well on this I definitively do not agree :-) > 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) > > Given these points, I think that some of the parameters names proposed in > the draft actually DO inherently enhance a module reusability: > For point 2: source, template, options (with might make useless almost any > additional application specific configuration parameter), dir_source (and > dir_* ) > For point 3: status, autorestart (poor name), audits, noops > For point 4: package, service, file_path, dir_path > For point 5: my_class resources_hash > > But maybe we have different semantic nuances for the term "modules' > reusability". > Evidently so. For the most part, what you said does not conflict with what I said; you were just more specific. Where we differ is that I am distinguishing "reusability" from *ease* of reuse. I agree that all of your items 1 - 6 are factors that improve modules' reusability. I assert, however, that the names by which those particular knobs are referenced do not constitute essential reusability factors, but rather ease of use factors. Basically, I am drawing the line at having to modify the code to use a third-party module. The module is "reusable" if I do not have to modify it, even if I have to study it to determine how to use it. It is easy to use if it presents a coherent, intuitive external interface. Almost all naming considerations fall into the latter category. Moreover, any ease of use advantage of such a convention is limited to those users who buy in to the convention. Such buy-in is unlikely to arise from a standard-setting effort alone. > > I agree that the interoperability part is not fully dependent on naming > standards. > Aa a partial solution for this I have thought about the usage of a > "dependency_class" to contain in a single, replaceable, class all the > external dependencies, and eventually tweaking the Modulefile and the > puppet module command to manage soft-dependencies and reduce conflicts > modules Forge modules (more details on this on the blog post linked before). > I don't see it as a perfect solution but that's something that can be done > now (without extra code if not for the Forge integration) and very quickly. > I have some issues with that approach, but I'm going to disregard them for now because that topic is largely beyond the stated scope of the naming conventions and convention-drafting effort we are discussing. > >> I think being able to use another class in a drop-in way is not the >> value I see in parameter naming 'recommendations'. I personal see >> value in the ease of use more than anything, if parameters are >> similarly named between classes, when you go to use them you don't >> have to interrupt, double check with the docs what this class/define >> uses, then modify your parameter name accordingly. Its a reduction in >> surprise if anything. An example would be the 'package' parameter, >> versus 'packages' ... if I didn't have to stop and check which one it >> is for my XYZ class it might save time and mistakes *shrug*. >> > > Let me clarify that hardly in my dreams I could imagine seamless drop-in > replacements, but naming standards+dependency_class pattern CAN make > interoperability much easier. > > So, then, this really isn't just a question of naming things, as previously claimed? I mean, I know I made that very observation in my previous post, but I had assumed that it was just an aspect of the proposal that you hadn't recognized and appreci
Re: [Puppet Users] The handy Grail of Modules Standards
Some personal notes among the lines... On Tuesday, June 18, 2013 6:35:18 PM UTC+2, Ken Barber wrote: > > > Although I agree that to be reusable, modules need to provide certain > types > > of levers, knobs, and switches, as appropriate for their scopes, I think > the > > case is weak for those controls needing to be called by the same names. > At > > best, naming conventions for such things might improve ease of (re)use > for > > some people, but the key factor for reusability is not the names of the > > controls so much as their presence in the first place. > Well on this I definitively do not agree :-) 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) Given these points, I think that some of the parameters names proposed in the draft actually DO inherently enhance a module reusability: For point 2: source, template, options (with might make useless almost any additional application specific configuration parameter), dir_source (and dir_* ) For point 3: status, autorestart (poor name), audits, noops For point 4: package, service, file_path, dir_path For point 5: my_class resources_hash But maybe we have different semantic nuances for the term "modules' reusability". > > > I see implications for interoperability only insomuch as one imagines > > facilitating one module being a drop-in replacement for another, but (1) > > there's a lot more to that than just common naming, so (2) that kind of > > interoperability is unlikely to come about except by specific intention > > anyway, so in that case shared naming comes out as a project > requirement. > > To me, that moots any general parameter-naming standard as far as > > interoperability goes. > I agree that the interoperability part is not fully dependent on naming standards. Aa a partial solution for this I have thought about the usage of a "dependency_class" to contain in a single, replaceable, class all the external dependencies, and eventually tweaking the Modulefile and the puppet module command to manage soft-dependencies and reduce conflicts modules Forge modules (more details on this on the blog post linked before). I don't see it as a perfect solution but that's something that can be done now (without extra code if not for the Forge integration) and very quickly. > > I think being able to use another class in a drop-in way is not the > value I see in parameter naming 'recommendations'. I personal see > value in the ease of use more than anything, if parameters are > similarly named between classes, when you go to use them you don't > have to interrupt, double check with the docs what this class/define > uses, then modify your parameter name accordingly. Its a reduction in > surprise if anything. An example would be the 'package' parameter, > versus 'packages' ... if I didn't have to stop and check which one it > is for my XYZ class it might save time and mistakes *shrug*. > Let me clarify that hardly in my dreams I could imagine seamless drop-in replacements, but naming standards+dependency_class pattern CAN make interoperability much easier. For the other benefits, least surprise is one point, not small as it involves (let me copy and paste :-): - Better user experience (modules are easier to use and understand) - Quicker and more reliable Puppet manifests development (for basic functions you can expect predictable parameters) - More coherent and error proof Puppet setups but I see various other clear benefits, in the mid term: - The possibility to have an unified approach to smoke testing of common features - The possibility to have web front-ends and ENC that leverage on the standardized parameters - Easier integration with superclasses that expose their own parameters and use different modules to build up full applications stacks or complex setups that involve multiple modules. - A PuppetLabs and/or Community driven central repository of well tested and features rich unique Standard modules (it might be a subset of the Forge or a set of git repos with only one module for application) > > Is that valuable? Alas, I'm more of developer then user these days so > I would defer that to our users. As a developer though - I would find > it handy to have a gu
Re: [Puppet Users] The handy Grail of Modules Standards
> Although I agree that to be reusable, modules need to provide certain types > of levers, knobs, and switches, as appropriate for their scopes, I think the > case is weak for those controls needing to be called by the same names. At > best, naming conventions for such things might improve ease of (re)use for > some people, but the key factor for reusability is not the names of the > controls so much as their presence in the first place. > > I see implications for interoperability only insomuch as one imagines > facilitating one module being a drop-in replacement for another, but (1) > there's a lot more to that than just common naming, so (2) that kind of > interoperability is unlikely to come about except by specific intention > anyway, so in that case shared naming comes out as a project requirement. > To me, that moots any general parameter-naming standard as far as > interoperability goes. I think being able to use another class in a drop-in way is not the value I see in parameter naming 'recommendations'. I personal see value in the ease of use more than anything, if parameters are similarly named between classes, when you go to use them you don't have to interrupt, double check with the docs what this class/define uses, then modify your parameter name accordingly. Its a reduction in surprise if anything. An example would be the 'package' parameter, versus 'packages' ... if I didn't have to stop and check which one it is for my XYZ class it might save time and mistakes *shrug*. Is that valuable? Alas, I'm more of developer then user these days so I would defer that to our users. As a developer though - I would find it handy to have a guide for common things, I'm a pedant when it comes to naming and if someone already came up with a name for me, I would probably use it, presuming others have thought through any naming consequences. > None of that is a fundamental reason to object to the effort, but I'm not > seeing any promise of significant benefit to motivate me to participate > actively. > > I do have a bona fide objection, however: although the effort is cast at > this point as being aimed exclusively at parameter naming, by implication it > also covers elements of module structure, organization, and style as well, > as the things being named have to exist for the standard to be relevant. I > do understand that the intention is not to make all the standardized > controls mandatory for every module, but for those that a given module does > provide, even the standard's limited reusability and interoperability goals > are not served if those controls are not located where the standard > anticipates (which is for the most part on a single front-end class). I've been pondering this situation as well. I presume in a world where such recommendations become commonly used, the outcome would be surprise at a missing 'recommended' parameter, then a subsequent bug raised on the module due to its lack. This might be considered a positive or negative. If the parameter name was named 'something else' due to a feeling that the 'standard' is not covering a developers needs, then this could be annoying to have that discussion _yet again_. If however the functionality is simply missing - this becomes a BAU patch (like the lint patches we see all the time) and probably a positive feature request. Of course, this all depends on how good the recommendations are. Having looked through the document I think some of them are obvious, and require less debate while other recommendations are less obvious/contentious. > Personally, I would rather see a white paper explaining what kinds of > controls need to be available to facilitate reusability of various kinds of > modules, and, optionally, setting out one or more models of how a module can > provide those controls. Regardless of the nature of the paper's authorship, > this feels like it should be a position paper, not a proposed standard. Fair point, its a difficult document to position precisely. I guess I foresee this as something that should be a part of a guide for writing modules then any hard/fast rule or 'standard'. ken. -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Monday, June 17, 2013 9:32:36 AM UTC-5, Alessandro Franceschi wrote: > > Puppet is a language and so people do the same things in different ways, > and they all work and do what they are supposed to do. > But if we think about modules REUSABILITY and INTEROPERABILITY some > patterns have to be followed. > Some of the parameters described in the document are somehow REQUIRED, > IMHO, if you want to make a really reusable module (for example the ones > that let you decide how to manage your configuration files... if you > enforce a logic in a module or a specific template and don't allow override > by users, then you are not making a reusable module, so for example a > parameter like "template" is just needed). > So, since, at least some of, these parameters are needed for a reusable > module it's just a matter of defining few naming conventions (and managing > external modules dependencies in a sane way) to make different modules > happily live better together. > Although I agree that to be reusable, modules need to provide certain types of levers, knobs, and switches, as appropriate for their scopes, I think the case is weak for those controls needing to be called by the same names. At best, naming conventions for such things might improve *ease* of (re)use for some people, but the key factor for reusability is not the names of the controls so much as their presence in the first place. I see implications for interoperability only insomuch as one imagines facilitating one module being a drop-in replacement for another, but (1) there's a lot more to that than just common naming, so (2) that kind of interoperability is unlikely to come about except by specific intention anyway, so in that case shared naming comes out as a project requirement. To me, that moots any general parameter-naming standard as far as interoperability goes. None of that is a fundamental reason to object to the effort, but I'm not seeing any promise of significant benefit to motivate me to participate actively. I do have a bona fide objection, however: although the effort is cast at this point as being aimed exclusively at parameter naming, by implication it also covers elements of module structure, organization, and style as well, as the things being named have to exist for the standard to be relevant. I do understand that the intention is not to make all the standardized controls mandatory for every module, but for those that a given module does provide, even the standard's limited reusability and interoperability goals are not served if those controls are not located where the standard anticipates (which is for the most part on a single front-end class). Personally, I would rather see a white paper explaining what kinds of controls need to be available to facilitate reusability of various kinds of modules, and, optionally, setting out one or more models of how a module can provide those controls. Regardless of the nature of the paper's authorship, this feels like it should be a position paper, not a proposed standard. 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Tuesday, June 18, 2013 11:16:15 AM UTC+2, Matthias Saou wrote: > > On Mon, 17 Jun 2013 07:32:36 -0700 (PDT) > Alessandro Franceschi > wrote: > > > Thanks for your opinion, even if I don't fully agree with it. > > Puppet is a language and so people do the same things in different > > ways, and they all work and do what they are supposed to do. > > But if we think about modules REUSABILITY and INTEROPERABILITY some > > patterns have to be followed. > > Some of the parameters described in the document are somehow > > REQUIRED, IMHO, if you want to make a really reusable module (for > > example the ones that let you decide how to manage your configuration > > files... if you enforce a logic in a module or a specific template > > and don't allow override by users, then you are not making a reusable > > module, so for example a parameter like "template" is just needed). > > So, since, at least some of, these parameters are needed for a > > reusable module it's just a matter of defining few naming > > conventions (and managing external modules dependencies in a sane > > way) to make different modules happily live better together. > > > > Note, I don't say that ALL the modules should have ALL these > > parameters, I'd consider these Standard Namings as suggestions which > > people may decide to follow or not (somehow similar to the Code Style > > suggestions, which leverage the style of the Puppet code and have > > found tools like puppet-lint to validate them). Once enough good and > > prominent Puppet modules will follow these naming conventions, it > > will be easier for people to switch modules, integrate the best ones > > from different sources (without forking them) , use these parameters > > from a WEB interface, a a standard framework from smoke testing and > > have the benefits which are better described in the blog post. > > > > Note also that these proposals are based on the current Puppet > > language specifications, I want to start from what can be used now, > > with an eye on the evolution on Puppet, but with still feet on the > > ground: nothing new or to invent, just few basic naming convention to > > agree upon and *suggest*. > > > > I still think that this is at hands reach :-) > > This is definitely a good initiative, what I'm just saying is that > you've opened a can of worms :-) > Lol, we have to do that sooner or later, I think :-D And the sooner, the better. > > The initial step of creating common guidelines for parameter names is > nice, as it can create some consistency across modules, and ease work > sharing as well as lower the learning curve for people using 3rd party > modules. But it would need to be official (in the puppet documentation > as best practices, for instance) and/or enforced on the forge, to > become really useful. > I definitively agree. This is something that should be endorsed if not managed directly by PuppetLabs. Anyway I would not "enforce" the use of standard params, but somehow "certify" the modules that provide them (eventually defining different "levels" of standard params coverage) so that you know you can use them with established patterns (and in the future maybe test them with standard procedures and integrate them in an ENC that explicitly supports and exposes these standard parameters) > > And after that, things quickly get exponentially complex IMHO. A few > examples from the top of my head : > > * Naming the modules themselves. > Right, even if, besides few cases with somehow flurry namings (apache or httpd? ssh or openssh?), generally the name of the module is already quite standard. > * Naming the classes and definitions inside the modules. > * Multiple modules requiring the same packages (If my module needs >rsync, yours too, where do we put the common virtual resource?). > This is a wide and tricky issue. My naif approach is the definition of a dependency_class parameter where external resources like rsync are managed (and you can provide a custom dependency_class where you manage the required resources in the way you want). For the installation of simple packages I'd currently use/recommend the not perfect "if ! defined" approach (always in the dependency_class). When the language will provide a smarter solution, we can follow it, some past discussion on possible solutions there has been in the list, in order to work they definitively have to be shared by the modules (so they fit well in the "standard module" pattern). Some of them required enhancements to the DSL some not, being a Puppet user I prefer to stick to current language syntax. > * The use of author-specific common modules (I don't like taking a >johndoe/apache module and noticing I then need johndoe/common). > I'd try to leverage modules on stdlib as much as possible, but at the same time some "local common" modules are sometimes needed. It doesn't harm to have them in your modulep
Re: [Puppet Users] The handy Grail of Modules Standards
On Mon, 17 Jun 2013 07:32:36 -0700 (PDT) Alessandro Franceschi wrote: > Thanks for your opinion, even if I don't fully agree with it. > Puppet is a language and so people do the same things in different > ways, and they all work and do what they are supposed to do. > But if we think about modules REUSABILITY and INTEROPERABILITY some > patterns have to be followed. > Some of the parameters described in the document are somehow > REQUIRED, IMHO, if you want to make a really reusable module (for > example the ones that let you decide how to manage your configuration > files... if you enforce a logic in a module or a specific template > and don't allow override by users, then you are not making a reusable > module, so for example a parameter like "template" is just needed). > So, since, at least some of, these parameters are needed for a > reusable module it's just a matter of defining few naming > conventions (and managing external modules dependencies in a sane > way) to make different modules happily live better together. > > Note, I don't say that ALL the modules should have ALL these > parameters, I'd consider these Standard Namings as suggestions which > people may decide to follow or not (somehow similar to the Code Style > suggestions, which leverage the style of the Puppet code and have > found tools like puppet-lint to validate them). Once enough good and > prominent Puppet modules will follow these naming conventions, it > will be easier for people to switch modules, integrate the best ones > from different sources (without forking them) , use these parameters > from a WEB interface, a a standard framework from smoke testing and > have the benefits which are better described in the blog post. > > Note also that these proposals are based on the current Puppet > language specifications, I want to start from what can be used now, > with an eye on the evolution on Puppet, but with still feet on the > ground: nothing new or to invent, just few basic naming convention to > agree upon and *suggest*. > > I still think that this is at hands reach :-) This is definitely a good initiative, what I'm just saying is that you've opened a can of worms :-) The initial step of creating common guidelines for parameter names is nice, as it can create some consistency across modules, and ease work sharing as well as lower the learning curve for people using 3rd party modules. But it would need to be official (in the puppet documentation as best practices, for instance) and/or enforced on the forge, to become really useful. And after that, things quickly get exponentially complex IMHO. A few examples from the top of my head : * Naming the modules themselves. * Naming the classes and definitions inside the modules. * Multiple modules requiring the same packages (If my module needs rsync, yours too, where do we put the common virtual resource?). * The use of author-specific common modules (I don't like taking a johndoe/apache module and noticing I then need johndoe/common). But don't get me wrong, I like where this is headed, and will participate as much as I can. Matthias -- Matthias Saou ██ ██ ██ ██ Web: http://matthias.saou.eu/ ██ Mail/XMPP: matth...@saou.eu ██ ██ GPG: 4096R/E755CC63██ ██ ██ 8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██ 21A9 7A51 7B82 E755 CC63 -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
On Monday, June 17, 2013 1:17:45 PM UTC+2, Matthias Saou wrote: > > Hi, > > First off... is these some pun I'm not getting, or was it supposed to > be "Holy Grail"? Just wondering :-) > It's holy but is also handy, as I think it's just at hands reach. > > Also, when I read "Puppet Modules Standard naming conventions", I > thought it was just about module names, but it seems to be about > parameter naming inside all of the module resources. > > After reading the shared Google document, I got reminded a lot of > what I've seen happen with RPM packaging over the years. Lot of > similarities, since both Puppet and RPM are tools which give a lot of > freedom in the way things get implemented. > > Think of GNU/Linux distributions such as Fedora, RHEL, Mandriva, SuSE, > etc. which all use RPM packages as their building blocks : They are not > to be considered compatible for various reasons, yet they could have > been in theory. > > With Puppet, each author is currently like each distribution using RPM : > Doing things in a given ecosystem, with implementation choices being > made, all of which can easily differ enough to make modules from > different authors incompatible. > > Now the problem that I see here is that with RPM things have never been > able to converge on a global scale. There isn't one single right answer, > and it has never been the tool's goal to enforce how it's being used, > especially when it's purely cosmetic or related to details that many > find irrelevant. > > Where I'm trying to get at is that I see Puppet as being similar in the > fact that it doesn't try to enforce any high-level cosmetic choices, > such as parameter names, and I think it's the right behavior for the > basic tool itself. > > From there, I'm all for trying to "standardize" something, but that's > actually much harder than it seems, and won't work unless there is some > enforcing being done at some point. One possibility would be to have a > review-based approval process for forge modules, where guidelines would > have to be enforced before a module gets published. Of course, that's a > lot of time and resources, for what boils down to being considered > "boring work" by most. It's what works for many GNU/Linux distributions > (Debian, Fedora, etc.). > > Just my 2¢ ;-) > Thanks for your opinion, even if I don't fully agree with it. Puppet is a language and so people do the same things in different ways, and they all work and do what they are supposed to do. But if we think about modules REUSABILITY and INTEROPERABILITY some patterns have to be followed. Some of the parameters described in the document are somehow REQUIRED, IMHO, if you want to make a really reusable module (for example the ones that let you decide how to manage your configuration files... if you enforce a logic in a module or a specific template and don't allow override by users, then you are not making a reusable module, so for example a parameter like "template" is just needed). So, since, at least some of, these parameters are needed for a reusable module it's just a matter of defining few naming conventions (and managing external modules dependencies in a sane way) to make different modules happily live better together. Note, I don't say that ALL the modules should have ALL these parameters, I'd consider these Standard Namings as suggestions which people may decide to follow or not (somehow similar to the Code Style suggestions, which leverage the style of the Puppet code and have found tools like puppet-lint to validate them). Once enough good and prominent Puppet modules will follow these naming conventions, it will be easier for people to switch modules, integrate the best ones from different sources (without forking them) , use these parameters from a WEB interface, a a standard framework from smoke testing and have the benefits which are better described in the blog post. Note also that these proposals are based on the current Puppet language specifications, I want to start from what can be used now, with an eye on the evolution on Puppet, but with still feet on the ground: nothing new or to invent, just few basic naming convention to agree upon and *suggest*. I still think that this is at hands reach :-) -- 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.
Re: [Puppet Users] The handy Grail of Modules Standards
Hi, First off... is these some pun I'm not getting, or was it supposed to be "Holy Grail"? Just wondering :-) Also, when I read "Puppet Modules Standard naming conventions", I thought it was just about module names, but it seems to be about parameter naming inside all of the module resources. After reading the shared Google document, I got reminded a lot of what I've seen happen with RPM packaging over the years. Lot of similarities, since both Puppet and RPM are tools which give a lot of freedom in the way things get implemented. Think of GNU/Linux distributions such as Fedora, RHEL, Mandriva, SuSE, etc. which all use RPM packages as their building blocks : They are not to be considered compatible for various reasons, yet they could have been in theory. With Puppet, each author is currently like each distribution using RPM : Doing things in a given ecosystem, with implementation choices being made, all of which can easily differ enough to make modules from different authors incompatible. Now the problem that I see here is that with RPM things have never been able to converge on a global scale. There isn't one single right answer, and it has never been the tool's goal to enforce how it's being used, especially when it's purely cosmetic or related to details that many find irrelevant. Where I'm trying to get at is that I see Puppet as being similar in the fact that it doesn't try to enforce any high-level cosmetic choices, such as parameter names, and I think it's the right behavior for the basic tool itself. >From there, I'm all for trying to "standardize" something, but that's actually much harder than it seems, and won't work unless there is some enforcing being done at some point. One possibility would be to have a review-based approval process for forge modules, where guidelines would have to be enforced before a module gets published. Of course, that's a lot of time and resources, for what boils down to being considered "boring work" by most. It's what works for many GNU/Linux distributions (Debian, Fedora, etc.). Just my 2¢ ;-) Matthias -- Matthias Saou ██ ██ ██ ██ Web: http://matthias.saou.eu/ ██ Mail/XMPP: matth...@saou.eu ██ ██ GPG: 4096R/E755CC63██ ██ ██ 8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██ 21A9 7A51 7B82 E755 CC63 -- 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.
[Puppet Users] The handy Grail of Modules Standards
Dear all, I'd like to submit to the list's attention this post about Puppet Modules Standard naming conventions: http://www.example42.com/?q=The_handy_Grail_of_Modules_Standards and this working draft of a proposal for a version 0.0.1 of them: https://docs.google.com/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA/edit?usp=sharing The topic is not new, and on this list there have already been various discussions on how to manage modules' interoperability ( for example this interesting one on cross-modules dependencies: https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/modules$20standards|sort:date/puppet-users/Fvl0aOe4RPE) . Along with the current discussions on the topic and the Puppet evolution, I think that few simple *suggested* naming conventions on common parameters for classes and defines would benefit a lot the module's ecosystem with a small effort. I hope the discussion will have a real follow up, this time, and possibly move under the more authoritative PuppetLabs umbrella, for the moment is just a personal proposal, even if shared, at least in the intentions, with many modules' authors and Puppetteers. You can actively contribute to the proposed naming standards on the above Google document (let me know your gmail account) and you are invited to comment here what do you think of this (not new) idea: if you think that starting from simple naming convention is a step to be done, what's your general idea on the proposed naming standards, if you have better ideas on naming and approach. Let's grab this handy Grail :-) Alessandro Franceschi Example42 -- 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.
