Hi Gayan,

Yes its in hiera.yaml file, *deployment_pattern* and *deployment* are
factors we referred.

---

:backends:

  - yaml

:yaml:

  :datadir:
/etc/puppet/environments/%{::environment}/hieradata/%{::deployment}

:hierarchy:

  - "%{::deployment_pattern}/hosts"

  - "%{::deployment_pattern}/%{::clientcert}"

  - "%{::deployment_pattern}/pattern"

  - database

  - datasources

  - common

Thanks,
Krishantha.

On Sat, Dec 5, 2015 at 11:26 PM, Gayan Gunarathne <gay...@wso2.com> wrote:

> Hi Krishantha,
>
> On Sat, Dec 5, 2015 at 9:32 AM, Krishantha Samaraweera <
> krishan...@wso2.com> wrote:
>
>> Hi Imesh,
>>
>>
>> On Fri, Dec 4, 2015 at 10:12 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>>
>>> 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.
>>>
>>
>> +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 <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
>>>
>>>
>>
>>
>> --
>> Krishantha Samaraweera
>> Senior Technical Lead - Test Automation
>> Mobile: +94 77 7759918
>> WSO2, Inc.; http://wso2.com/
>> lean . enterprise . middleware.
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead, WSO2 Inc. (http://wso2.com)
> Committer & PMC Member, Apache Stratos
> email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
>
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Krishantha Samaraweera
Senior Technical Lead - Test Automation
Mobile: +94 77 7759918
WSO2, Inc.; http://wso2.com/
lean . enterprise . middleware.
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to