Hi, 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.
I tried to implement this using sub-modules. I created two repositories, one for common puppet artifacts[1] and other for wso2esb puppet artifacts [2]. I added common artifacts as a submodule to wso2esb artifacts. I encounter the following issue when using submodules. - 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]. 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. AFAIU it is not straight forward to create correct puppet structure due to these limitations in sub-modules. Appreciate your thoughts on this. [1] https://github.com/anuruddhal/puppet-artifacts-common [2] https://github.com/anuruddhal/puppet-wso2esb [3] https://git-scm.com/docs/git-submodule [4] http://stackoverflow.com/questions/5303496/how-to-change-a-git-submodule-to-point-to-a-subfolder 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]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
