This is the discus about $subject. Currently, WSO2 Puppet Modules are tightly coupled to hiera to manage the data component. This brings a few limitations, and the main problem is not being able to the modules to puppet forge [1]. Ideally it should be possible to push the released modules to puppet forge and a user should be able to install those and refer them from their manifests.
One possible way to perform this decoupling is to use the roles and profiles pattern [2, 3]. In a nutshell, it adds abstractions on top of component modules, named as a 'profile' layer and a 'role' layer. If we apply the same concept to WSO2 puppet modules, we get a hierarchy similar to the following, using API Manager as an example: The data lookups are done at a higher layer rather than the component module layer. As shown in the figure above, the hiera lookup can be done at the profile level; common lookups in the base profile and the product specific lookups in the product specific profile. If a user just wants to pass parameters specifically to the module without using hiera, its possible to do so by performing a resource like invocation [4] with parameters. For trying out purposes, just including the relevant modules [4] will work as well. The default parameters will be in a params class. WSO2 puppet modules are more complex than the usual puppet modules we find in puppet forge. There is a large number of configuration parameters as well as a common base module involved. Most of the defined types are included in the base module; hence need to strike a balance between invoking all the defined types from the profile itself or doing a single invocation of the product module from the profile. The latter is more user friendly, where the former approach gives greater control of the module to the profile class. As a possible solution, I suggest the following: - aggregate the many fine grained defined types to a few types by introducing wrappers; typically these should be for cleaning + installation, configuring and starting the server. Basically these are like three stages in starting a carbon server from puppet [6]. - Add extension points to manage any type of resource which puppet supports at these stages (at installing, configuring and starting the server) [7] - Call the relevant module from the profile layer, passing all the data obtained via lookups/explicit data passing This will help to keep the puppet modules easy to use; a user needs to just include them in a manifest and run. Also it allows a certain amount of extendability as well. Please share your input. [1]. https://forge.puppet.com/ [2]. http://www.craigdunn.org/2012/05/239/ [3]. http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/ [4]. https://docs.puppet.com/puppet/latest/reference/lang_classes .html#using-resource-like-declarations [5]. https://docs.puppet.com/puppet/latest/reference/lang_classes .html#using-include [6]. https://github.com/isurulucky/puppet-modules/blob/master/modules/wso2am/manifests/init.pp [7]. https://github.com/isurulucky/puppet-modules/blob/master/modules/wso2am/manifests/init.pp#L118 -- Thanks and Regards, Isuru H. +94 716 358 048* <http://wso2.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
