Hi Thilina, Thanks for the inputs.
On Fri, Nov 27, 2015 at 2:00 PM, Thilina Piyasundara <[email protected]> wrote: > Hi Isuru, > > Just to clarify, please refer to those inline comments and let us know if > you have a different view. > > On Fri, Nov 27, 2015 at 1:18 PM, Isuru Haththotuwa <[email protected]> > wrote: > >> Hi, >> >> The requirement is to automate the configurations dynamically in a >> serverless manner (without a puppet master), >> > specifically when running PPaas on docker/kubernetes. >> > This is not specific to docker containers. We can use same thing (puppet > apply) for VMs if needed. > Agreed, but we already have a working solution that we widely use for VM scenario. The requirement for serverlsess puppet came because of docker use case. > >> The puppet modules that are currently used (for VM scenario) can be >> re-used, with one change. >> > So we *should* use the same module. Then we don't need to maintain 2 > distributions. We need to update existing modules to cater this requirement > if those are lagging. > +1 > > That difference is the need include the nodes definitions (site.pp) in >> each puppet module >> > We don't include site.pp within the puppet module. ideally we shouldn't > touch a puppet module if there is no custom changes. I think you have done > it correctly but telling something different :D > > > > >> (can skip this it only a single module is used for a node; currently in >> the puppet master based deployment there are several modules referred in a >> single node definition). >> > In docker we only run a single server but in order to start a single > server we may refer several modules. As an example, we have a common module > called 'wso2base' which stores configs common to a deployment. If we need > to start an APIM server in a docker container we need to use both > 'apimanager' and 'wso2base' modules. > This is the exact reason why I thought of including a layer on top of modules. If this is not the correct practice, we can use puppet apply for all modules sequentially, or else use inheritance/composition. > >> A very basic puppet module can have a structure roughly similar to the >> following: >> >> ├── files >> ├── manifests >> │ └── site.pp >> ├── modules >> │ └── test >> │ └── manifests >> │ ├── init.pp >> │ └── site.pp >> ├── puppet.conf >> └── templates >> >> This same structure can be re-used in both puppet scenarios; where the >> deployment has a master and where it does not have a master. >> >> In the serverless puppet scenario there is a requirement to pass data to >> the modules. For this, its possible to use facters (similar to the >> deployments that include puppet master). For this, need to do the following: >> >> >> 1. expose the data as a environment variable, with FACTER_ prepended >> to the variable name [1] >> >> Try to use the ruby facter extension to expose environment variable as > facters. > > Will look in to that. > >> 1. >> 2. Access the variable in the manifest file [2] >> >> After the data is exposed as environment variables, can run the puppet >> apply command pointing to the relevant module [3]. >> > As I know it should be the module path, but not the specific module. > > Yes, that is correct. Wrong wording used by me. > After the configurations is done, its possible to re-use the same approach >> that is used currently to push the configured templates to the product with >> puppet master based deployment. >> >> [1]. export *FACTER_message*="test puppet apply message" >> >> [2]. >> >> class test { >> >> file { "/var/tmp/testfile": >> ensure => "present", >> owner => "root", >> group => "root", >> mode => "664", >> content => "*$message*" >> } >> >> } >> >> [3]. puppet apply --modulepath *<location_of_modules>* -e "include >> *<classname>*" >> >> -- >> Thanks and Regards, >> >> Isuru H. >> +94 716 358 048 >> >> >> Regards, > Thilina. > > > -- Thanks and Regards, Isuru H. +94 716 358 048* <http://wso2.com/>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
