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