Details
-
Improvement
-
Status: Resolved
-
Blocker
-
Resolution: Won't Fix
-
0.5.0
-
None
Description
Our current puppet code is now showing its age (after all it was originally developed to run on, gasp, Puppet 0.25!). It would be nice to re-factor it so we can take care of the following shortcomings:
- namespace all of our code under bigtop and get rid of extra hadoop- prefixes. For example, zookeeper server class will be accessible as bigtop::zookeeper::server
- as a consequence of doing #1 we will be consolidating all of our code into a single bigtop module. Now, this could be controversial at first, but lets face – Bigtop is an integration platform so chance of somebody using our zookeeper module with Adobe's hadoop module to deploy a cluster are pretty low. Also, moving everything into a single module will make it way easier for us to register it at Puppet Forge (http://forge.puppetlabs.com/) and engage additional community that way
- make all of our code based on parameterized classes and get rid of all the dynamic scope lookups (which is deprecated in Puppet 3.0 anyway) and global variable settings.
- separate data from puppet code as descibed over here: https://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/
- pursue the roles/profiles class paradigm http://www.craigdunn.org/2012/05/239/
If this still sounds pretty opaque to you, I'll post some POC code over the weekend so you can take a closer look.
Also, if you have any other Puppet concerns – please jump right in – now is a good time to do a bit of spring cleaning.
Finally, given that we will be introducing a brand new module (bigtop) all of our existing Puppet code will remain in place at least till Bigtop 0.7.0. By that time if the new one works well, we can deprecate the old one.
Attachments
Attachments
Issue Links
- relates to
-
BIGTOP-1352 Refactor puppet code for installing JDK7
-
- Resolved
-