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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
