Hi Krishantha, On Sat, Dec 5, 2015 at 9:32 AM, Krishantha Samaraweera <[email protected]> wrote:
> Hi Imesh, > > > On Fri, Dec 4, 2015 at 10:12 PM, Imesh Gunaratne <[email protected]> wrote: > >> Hi Krishantha, >> >> On Fri, Dec 4, 2015 at 12:36 PM, Krishantha Samaraweera < >> [email protected]> 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. >> > > +1 for looking into existing scripts and trying to reuse them. Yes there > are many things that we can make more 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? >> > > No, however we used factors to store deployment pattern and product name. > How do you use factors with the Hiera? Are you use the hierarchy[1]? [1] https://docs.puppetlabs.com/hiera/1/variables.html#where-to-interpolate-data By changing those factors different deployment patterns can be triggered > though Jenkins. We used below Mcollective command to change factors in all > agent machines. This helps us to trigger deployments though Jenkins. > > *mco shell run 'rm /etc/facter/facts.d/deployment_pattern.txt;mkdir -p > /etc/facter/facts.d; echo "deployment_pattern=pattern1" >> > /etc/facter/facts.d/deployment_pattern.txt'* > > So if you can consider about factors to hold high level deployment options > then that would be very continuous delivery friendly option. > > Thanks, > Krishantha. > > > >>> 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 <[email protected]> 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 >> >> > > > -- > Krishantha Samaraweera > Senior Technical Lead - Test Automation > Mobile: +94 77 7759918 > WSO2, Inc.; http://wso2.com/ > lean . enterprise . middleware. > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Gayan Gunarathne Technical Lead, WSO2 Inc. (http://wso2.com) Committer & PMC Member, Apache Stratos email : [email protected] | mobile : +94 775030545 <%2B94%20766819985>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
