Hi Imesh, Hieradata can be kept inside the puppet-<product> repository for the time > being. Will move them to the paas-artifacts repositories later on once we > decouple hieradata from the puppet module.
+1 for this until we decouple hieradata. On Sat, Aug 6, 2016 at 10:05 AM, Imesh Gunaratne <[email protected]> wrote: > Hi Anuruddha, > > On Fri, Aug 5, 2016 at 7:30 PM, Anuruddha Liyanarachchi < > [email protected]> wrote: >> >> >> - Submodule will always be cloned into an uneditable directory : >> By default, this directory name will be same as the repo name of >> submodule [3]. This can be changed by specifying a relative path, but the >> submodule will always be cloned into a separate directory. >> >> This directory cannot be modified and partial cloning is also not >> possible [4]. >> > > Yes, that's by design. > > >> >> In order for puppet apply to work we need to add wso2esb modules folder >> inside <puppet_common_artifacts>/moduels folder. Similarly, hieradata >> should be merged. >> > > Hieradata can be kept inside the puppet-<product> repository for the time > being. Will move them to the paas-artifacts repositories later on once we > decouple hieradata from the puppet module. > >> >> AFAIU it is not straight forward to create correct puppet structure due >> to these limitations in sub-modules. >> Appreciate your thoughts on this. >> > > Please see [5] to see how I created puppet-base and puppet-esb > repositories without any problem: > > [5] https://github.com/imesh/puppet-base > [6] https://github.com/imesh/puppet-esb > > Thanks > >> >> On Fri, Aug 5, 2016 at 1:25 PM, Akila Ravihansa Perera < >> [email protected]> wrote: >> >>> Hi, >>> >>> We have come across several issues in current repository structure and >>> release model of Puppet, Dockerfiles, Mesos artifacts, Kubernetes artifacts >>> etc. (deployment artifacts). To name a few; >>> - Publishing Puppet modules to PuppetForge is problematic >>> - Releasing planning is bit complicated since all the Puppet modules >>> should be released >>> - Not possible to release a specific Puppet module for a product since >>> all the modules resides in a single repo >>> >>> To overcome these issues we can split each Puppet module, Dockerfile, >>> Mesos artifacts, K8S artifacts into its own repo. For eg: >>> >>> >>> - wso2/puppet-<product> >>> - wso2/docker-<product> >>> - wso2/aws-artifacts-<product> >>> - wso2/mesos-artifacts-<product> >>> - wso2/kubernetes-artifacts-<product> >>> >>> >>> Now there are common Puppet resources being used by product modules, and >>> these can be hosted in wso2/puppet-common repo. Similarly we can host >>> common artifacts in wso2/mesos-artifacts-common, >>> wso2/kubernetes-artifacts-common >>> >>> Also we can host Hieradata in the same repo as platform specific repo. >>> For eg: >>> >>> >>> - mesos-artifacts-<product>/hieradata/ >>> - kubernetes-artifacts-<product>/hieradata/ >>> >>> >>> Common Hiera data for each platform can be hosted in wso2/ >>> <platform>-artifacts-common repo. We can ship default Hiera data with a >>> Vagrantfile in the wso2-<product> repo. >>> >>> Using this approach it would be much easier to do frequent releases of >>> Puppet modules, especially when a new product is released. By having common >>> repos (puppet-common, docker-common etc.) as Git sub-modules of product >>> specific repos (puppet-wso2esb, docker-wso2esb), transition will be >>> seamless for the users and no additional maintenance cost to developers. >>> >>> Another concern is release versioning for Puppet modules. As per some >>> offline discussions, having product version number + puppet version suffix >>> seems to be appropriate since it would be easier for users find the >>> compatible and latest Puppet module for a specific product. >>> >>> *Another option* is to make Puppet module for specific product >>> compatible across all the versions released under the same platform >>> version. For eg; >>> wso2esb-4.9.0 and wso2esb-5.0.0 which is released under platform version >>> 4.4.0 should be supported by puppet-wso2esb 4.4.0 family. Older versions of >>> puppet-wso2esb may not support products released after, but it should be >>> backward compatible with all the products released under the same platform >>> version. >>> >>> Please note that repo names are not finalized yet and are still open to >>> suggestions. Please do share your thoughts. >>> >>> Thanks. >>> >>> -- >>> Akila Ravihansa Perera >>> WSO2 Inc.; http://wso2.com/ >>> >>> Blog: http://ravihansa3000.blogspot.com >>> >> >> >> >> -- >> *Thanks and Regards,* >> Anuruddha Lanka Liyanarachchi >> Software Engineer - WSO2 >> Mobile : +94 (0) 712762611 >> Tel : +94 112 145 345 >> a <[email protected]>[email protected] >> > > > > -- > *Imesh Gunaratne* > Software Architect > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > -- *Thanks and Regards,* Anuruddha Lanka Liyanarachchi Software Engineer - WSO2 Mobile : +94 (0) 712762611 Tel : +94 112 145 345 a <[email protected]>[email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
