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 <raviha...@wso2.com > 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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture