On Wed, Aug 31, 2016 at 12:52 PM, Pubudu Gunatilaka <[email protected]> wrote:
> > 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. > Just to clarify, how is the overall user experience? Will users be able to do this? 1. Set up a new puppet server 2. puppet module install <wso2product> --version <wso2product-version> 3. Update site.pp file. 4. Copy hieradata files to the proper location and update configurations as needed 5. Run puppet agent Thanks > > [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> > > -- *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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
