Hi Anurudhdha, Are we not keeping default platform hieradata in the puppet module repo itself?
On Fri, Aug 26, 2016 at 9:44 AM, Akila Ravihansa Perera <[email protected]> wrote: > Hi, > > There is one catch with option 2; we need to track which Hiera > distribution (in platform specific artifacts repo) goes with which Puppet > release. This won't be a big issue but just wanted point out. > > Thanks. > > On Fri, Aug 26, 2016 at 9:05 AM, Rasanjaya Subasinghe <[email protected]> > wrote: > >> Hi all, >> >> The option 2 would be good for do the MC deployment. And other users can >> be used default profile with released puppet forge module. >> >> Thanks >> >> >> On Thursday, August 25, 2016, Anuruddha Liyanarachchi < >> [email protected]> wrote: >> >>> Hi Devs, >>> >>> We are in the process of restructuring and splitting the puppet modules >>> per product. As per the initial discussions, we have created separate >>> repositories per product puppet module and one common repository for puppet >>> base module. >>> >>> In order to publish puppet modules to puppet forge, we have decoupled >>> hieradata from puppet modules using profiles. Now the puppet modules are >>> capable of running without hieradata for the default profile. >>> >>> However, it is easier to do deployment using hieradata. The intention of >>> this mail is to discuss and finalize hieradata location. >>> >>> Appreciate your feedback on selecting an available option. >>> >>> Following are the available options: >>> >>> *1. Use one repository to keep all product hieradata.* >>> Pros: >>> - Easy to manage since all the hieradata are in one place. >>> - No data duplication >>> >>> Cons: >>> - Releasing hieradata with a product is not possible. >>> - Difficult to track changes. >>> >>> >>> *2. Keep hieradata with platform specific artifact repositories. >>> (kubernetes, mesos )* >>> Pros: >>> - Hieradata can be released with a product. >>> >>> Cons: >>> - Possible data duplication. >>> - Hieradata is a part of puppet and it is not related to mesos or >>> kubernetes >>> - Have to create repositories to store default hieradata. >>> >>> >>> *3. Create separate repositories per product to store hieradata. * >>> Pros: >>> - Product level hieradata separation. >>> - Easier to release and track changes. >>> >>> Cons: >>> - No of repositories are high. >>> - User experience will be not good as users will have to clone from >>> multiple locations. >>> >>> >>> >>> *4. Keep hieradata in the product puppet module repos with >>> .pmtignore file. *Pros: >>> - Minimum changes required. >>> - Can be released with product puppet modules. >>> >>> Cons: >>> - Most of the puppet repos don't contain hieradata >>> - Puppet recommends keeping hieradata separately from modules. >>> >>> >>> >>> -- >>> *Thanks and Regards,* >>> Anuruddha Lanka Liyanarachchi >>> Software Engineer - WSO2 >>> Mobile : +94 (0) 712762611 >>> Tel : +94 112 145 345 >>> [email protected] >>> >> >> >> -- >> ------------------------------------- >> Rasanjaya Subasinghe >> Software Engineer, Dev/Ops, WSO2 Inc. >> +94772250358 >> [email protected] >> >> > > > -- > Akila Ravihansa Perera > WSO2 Inc.; http://wso2.com/ > > Blog: http://ravihansa3000.blogspot.com > -- Thanks and Regards, Isuru H. +94 716 358 048* <http://wso2.com/>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
