Hi, We are currently working on wso2base module and wso2as module. As Imesh suggested we used a facter value to enable hieradata [1]. With this approach, we have to make sure hiera lookup should be defined in either in wso2base params.pp file or in the relevant product params.pp file based on the variable value assinging[2].
We have done the following changes to puppet modules. 1. Users need to install java separately before installing any wso2 product. But they can use the wso2base::java if needed [3]. 2. We have moved creating java system preferences directories to wso2base::system [4]. Earlier this was done under the wso2base::java class. 3. We are calling wso2base resources from the product init.pp file as in [5]. These resources are same for all the products and we can move all these resources to a single resource in wso2base. Then it would be difficult to do any changes as all these changes should be done in wso2base, which is the common module. [1] - https://github.com/wso2/puppet-base/blob/master/manifests/params.pp#L19 [2] - https://github.com/wso2/puppet-as/blob/master/manifests/init.pp#L21 [3] - https://github.com/isurulucky/puppet-modules/blob/master/modules/profiles/manifests/wso2am.pp#L44 [4] - https://github.com/wso2/puppet-base/blob/master/manifests/system.pp#L63 [5] - https://github.com/wso2/puppet-as/blob/master/manifests/init.pp#L76 Thank you! On Mon, Aug 29, 2016 at 6:53 PM, Imesh Gunaratne <[email protected]> wrote: > Hi Isuru, > > Thanks for the offline explanation on the proposed architecture! > Technically this looks impressive! Please find my thoughts below: > > I think it would be better if we can avoid introducing puppet profile > concept and try to add a separate pp file for hiera lookups within the same > puppet module. This file can be either shipped with the hiera-data > distribution or kept inside the puppet module with a switch which can be > changed using a facter variable. > > If so, users might only need to do following to set up a puppet > environment: > > 1. Install puppet server > 2. Install wso2 puppet module (example: puppet module install wso2esb > --version 5.0.0) > 3. If hiera-data is needed > 1. Extract wso2 product hiera-data distribution to puppet-home > 2. Set facter variable (use_hieradata=true) on client/puppet agent > side > 3. Update hiera-data files with required configuration values > 4. If not, set configuration values in params.pp file > 5. Trigger puppet agent > > Thanks > > On Tue, Aug 23, 2016 at 10:24 AM, Akila Ravihansa Perera < > [email protected]> wrote: > >> Hi Isuru, >> >> This is great! >> >> 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: >>> >> >> +1 for decoupling Hiera from Puppet modules. Data backend should be >> pluggable to a Puppet module. >> >> >>> 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. >>> >> +1. This approach gives the users a much balanced control + flexibility. >> But will there be any use of invoking a resource type after wso2 server is >> started? If there is such case, users can add that logic directly to the >> relevant module right? >> I was earlier under the opinion that we should make use of Puppet >> containment [1] to handle dependencies at the run time. But thinking again, >> it makes me wonder whether we need that kind of complexity at this point. >> Better to start with the simplest approach and let it evolve. >> >> >> -- >> Akila Ravihansa Perera >> WSO2 Inc.; http://wso2.com/ >> >> Blog: http://ravihansa3000.blogspot.com >> > > > > -- > *Imesh Gunaratne* > Software Architect > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > -- *Pubudu Gunatilaka* Committer and PMC Member - Apache Stratos Software Engineer WSO2, Inc.: http://wso2.com mobile : +94774078049 <%2B94772207163>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
