Hi Pubudu, Wouldn't it be more meaningful to call "dockerfile-" instead of "docker-"?
Thanks On Mon, Aug 8, 2016 at 12:02 PM, Pubudu Gunatilaka <pubu...@wso2.com> wrote: > Hi, > > Following are the proposed repo names for the existing puppet modules. > > Puppet Modules Repo Dockerfiles Repo Kubernetes Artifacts Repo Mesos > Artifacts Repo > Common Artifacts puppet-base docker-common kubernetes-artifacts-common > mesos-artifacts-common > WSO2 APIM puppet-apim docker-apim kubernetes-artifacts-apim > mesos-artifacts-apim > WSO2 AS puppet-as docker-as kubernetes-artifacts-as mesos-artifacts-as > WSO2 BPS puppet-bps docker-bps kubernetes-artifacts-bps > mesos-artifacts-bps > WSO2 BRS puppet-brs docker-brs kubernetes-artifacts-brs > mesos-artifacts-brs > WSO2 CEP puppet-cep docker-cep kubernetes-artifacts-cep > mesos-artifacts-cep > WSO2 DAS puppet-das docker-das kubernetes-artifacts-das > mesos-artifacts-das > WSO2 DSS puppet-dss docker-dss kubernetes-artifacts-dss > mesos-artifacts-dss > WSO2 ES puppet-es docker-es kubernetes-artifacts-es mesos-artifacts-es > WSO2 ESB puppet-esb docker-esb kubernetes-artifacts-esb > mesos-artifacts-esb > WSO2 GREG puppet-greg docker-greg kubernetes-artifacts-greg > mesos-artifacts-greg > WSO2 IS puppet-is docker-is kubernetes-artifacts-is mesos-artifacts-is > WSO2 MB puppet-mb docker-mb kubernetes-artifacts-mb mesos-artifacts-mb > > > We will include wso2greg and wso2greg_pubstore puppet modules in greg > puppet repo. Same is applied for IS as a key manager. This is until we > introduce patterns concept for puppet modules. > > Thank you! > > On Mon, Aug 8, 2016 at 11:54 AM, Anuruddha Liyanarachchi < > anurudd...@wso2.com> wrote: > >> 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 <im...@wso2.com> wrote: >> >>> Hi Anuruddha, >>> >>> On Fri, Aug 5, 2016 at 7:30 PM, Anuruddha Liyanarachchi < >>> anurudd...@wso2.com> 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 < >>>> raviha...@wso2.com> 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 <thili...@wso2.com>nurudd...@wso2.com >>>> >>> >>> >>> >>> -- >>> *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 <thili...@wso2.com>nurudd...@wso2.com >> > > > > -- > *Pubudu Gunatilaka* > Committer and PMC Member - Apache Stratos > Software Engineer > WSO2, Inc.: http://wso2.com > mobile : +94774078049 <%2B94772207163> > > -- *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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
