Hi Krishantha, On Fri, Dec 4, 2015 at 12:36 PM, Krishantha Samaraweera <krishan...@wso2.com > wrote:
> > We need to consider continues delivery aspects when designing these core > puppet modules. Some of the suggestions that you have mentioned are already > being implemented while automating APIM deployment patterns. If we can > review and adhere to the way automation team design puppet scripts that > would cut down any rework for our side. > +1 Yes definitely, we are now reviewing the API-M puppet module developed by your team, planning to take it as it is and do any necessary changes to make it generic. > Automation requirement is to do several deployments and run tests on those > deployments without any human interventions. We already completed POC of > this using puppet, Hiera, Mcollective and Jenkins. > Do you think Mcollective and Jenkins should be part of the generic puppet modules? > > IMO, as the first step we should review the Hiera data model and module > structure that we have introduced. And improve it if required or go for new > design. > +1 Will do. > > Also having environment concept (Development, production, QA) would help > us to manage/maintain puppet scripts more easily. > > Yes we noticed this in Hiera. We should be able to keep this feature in the generic puppet modules. Thanks > WDYT ? > > Thanks, > Krishantha. > > On Fri, Dec 4, 2015 at 12:19 AM, Imesh Gunaratne <im...@wso2.com> wrote: > >> Hi, >> >> We are now trying to refactor the puppet modules in [1] according to the >> best practices DevOps, Automation and Private PaaS teams found over the >> recent past on designing puppet modules. These include following: >> >> - Using Hiera for keeping site-specific data out of the manifests [2] >> - Use a base puppet module/class to implement common installation and >> configuration steps >> - Use one puppet module to install different versions of a product, >> product version to be given using a parameter (example: puppet module = >> wso2esb, product version = 4.9.0) >> - Eventually include multiple sets of templates for different >> versions of the product inside a single puppet module >> - Provide a version for the puppet module (example: puppet module = >> wso2esb, puppet module version = 1.0.0, product version = 4.9.0) >> - Implement unit tests for puppet modules [3] >> - Finally publish puppet modules in Puppet Forge >> - Afterwards users can either use puppet install or wget for >> installing puppet modules in their environments >> >> These puppet modules will be designed to support different deployment >> models: >> >> - Deploying WSO2 products on VMs using a Puppet Master >> - Building Docker images with Puppet Apply [4] for Kubernetes >> - Deploying WSO2 products on WSO2 Private PaaS >> - On VMs using a Puppet Master with runtime configurations >> - On Kubernetes using Puppet Apply with runtime configurations >> >> Please feel free to add your thoughts. >> >> [1] https://github.com/wso2/puppet-modules/ >> [2] https://docs.puppetlabs.com/hiera/latest/ >> [3] >> https://puppetlabs.com/blog/the-next-generation-of-puppet-module-testing >> [4] >> https://puppetlabs.com/blog/docker-and-puppet-for-application-management >> >> Thanks >> >> -- >> *Imesh Gunaratne* >> Senior Technical Lead >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: http://imesh.gunaratne.org >> Lean . Enterprise . Middleware >> >> > > > -- > Krishantha Samaraweera > Senior Technical Lead - Test Automation > Mobile: +94 77 7759918 > WSO2, Inc.; http://wso2.com/ > lean . enterprise . middleware. > -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
