Hi,
We have already created separate GitHub repos for Puppet modules so that
the Puppet module can be shipped as part of a product release. All common
resources and classes are still in wso2base Puppet module. We have
refactored the module structure which I'll highlight below;
Please refer to wso2base module [1] and wso2as module [2] which we have
implemented as a reference. We will discuss any improvements needed and
replicate the same structure for other modules.
- No more Hiera lookups in init.pp
All Hiera lookups have been moved to params classes in wso2base and
product module. All common parameters across products are defined in
wso2base/params.pp and product specific ones are defined in corresponding
product Puppet module
- Do Hiera lookups only when enabled via a facter
wso2base/params.pp lookup a facter named "use_hieradata" and decide
whether to take default values defined directly in params.pp or to perform
Hiera lookups. It would have been ideal if Hiera lookups are all done in a
separate layer (for eg: using roles and profiles pattern), but one problem
is users will have to write their own profiles module to use Hiera.
Maintaining profiles in our side would be an overhead. This is still open
to suggestions.
- Class parameters to override defaults in params.pp
Earlier Puppet modules were tightly coupled with Hiera so that users
were unable to simply include the module from site.pp and run it. Now all
the variables are defined as class parameters which takes common values
from wso2base/params.pp [4]. Default values for any product specific
parameters are kept in <product-module>/params.pp. For eg: [5]
Any user can now simply do the following in site.pp
class java -> class wso2as
Above manifest will configure wso2as using default configuration (vanilla
pack). Default values can be overridden by passing values. For eg: to set a
port offset of 10
$ports = {
offset => 10
}
class java ->
class { 'wso2as':
ports => $ports
}
- Class dependencies and containment
All base classes are contained in product module main class to enforce
the class dependency order [6].
- Data type validation
To enforce that parameters passed are in expected format and to help
with troubleshooting we have added validations in wso2base module which
checks whether data types passed for each parameter is correct [7].
- Vagrant setup
We have moved out the Vagrantfile, site.pp and hiera.yaml files to a
separate repo named "puppet-commons" [3]. This repo will contain any Puppet
related artifact which does not belong to a Puppet module. It has a
setup.sh shell script to create the PUPPET_HOME directly by cloning Puppet
module GitHub repos and merging Hieradata. Details about this setup.sh
script will be discussed in a separate thread.
Any developer who wants to try out a Puppet module can do so by performing
following steps;
1. Git clone puppet-commons
2. Run setup.sh
3. Provide PUPPET_HOME when prompted by setup.sh
4. Provide JDK file location product pack location when prompted
5. Goto puppet-commons/vagrant
6. Run vagrant up
Note that we have not fully implemented the end-to-end flow yet.
[1] https://github.com/wso2/puppet-base
[2] https://github.com/wso2/puppet-as
[3] https://github.com/wso2/puppet-commons
[4] https://github.com/wso2/puppet-base/blob/master/manifests/params.pp
[5] https://github.com/wso2/puppet-as/blob/master/manifests/params.pp#L29
[6] https://github.com/wso2/puppet-as/blob/master/manifests/init.pp#L115
[7]
https://github.com/wso2/puppet-base/blob/master/manifests/init.pp#L55-L86
Thanks.
--
Akila Ravihansa Perera
WSO2 Inc.; http://wso2.com/
Blog: http://ravihansa3000.blogspot.com
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
