Hi Akila, Thanks for your thought. Lets ship native hash merge data structures by default. Those who wants deeper merging can alter the merge behavior in hiera.yaml (:merge_behavior: deeper) and data structures in data yaml files. This doesn't involve any changes in puppet modules.
Thanks, Raj. On Fri, Dec 25, 2015 at 9:44 PM, Akila Ravihansa Perera <raviha...@wso2.com> wrote: > Hi Raj, > > It is true that native hash merging has its own limitations which would > lead to data duplication in some cases. But we need to analyze the > trade-off between data duplication against readability and trace-ability > aspects. IMHO, it's okay to have few data duplication if it makes things > more simple and less error prone. > > My concern is that what if this accidentally leads to unexpected data > merging? I understand that native merging will merge the top level keys as > well, but that is less susceptible for human errors compared to N-level > deep merge. > > Also have a look at Puppet official docs about deep merging [1]. Looks > like it is mainly intended for complex data structures and converting them > to Puppet resources. > > We can ask the users to create their own Hiera data structures with deeper > merging if they are comfortable with it. But given the additional > complexity involved in configuring and installing deep_merge library [2], > shall we ship native merge data structures by default? > > [1] > https://docs.puppetlabs.com/hiera/3.0/lookup_types.html#deep-merging-in-hiera > [2] > https://docs.puppetlabs.com/hiera/3.0/lookup_types.html#deep-merging-in-hiera > > Thanks. > > On Fri, Dec 25, 2015 at 10:45 AM, Rajkumar Rajaratnam <rajkum...@wso2.com> > wrote: > >> Hi Devs, >> >> We are using *Native* hash merge right now. *It merges only the >> top-level keys and values in each source hash. If the same key exists in >> both a lower priority source and a higher priority source, the higher >> priority value will be used. *But it doesn't allow us to override a >> nested hash. >> >> Lets take an example, >> >> *hiera.yaml* >> >> --- >> :hierarchy: >> - "wso2/%{::product_name}/%{::product_version}/default" >> - wso2/common >> :backends: >> - yaml >> :yaml: >> :datadir: "hieradata/%{::environment}" >> >> *wso2/common.yaml* >> >> --- >> # Deployment synchronization configuration >> wso2::dep_sync : >> enabled : false >> auto_checkout : true >> auto_commit : false >> repository_type : svn >> svn : >> url : http://svnrepo.example.com/repos/ >> user : username >> password : password >> append_tenant_id: true >> >> *wso2/wso2esb/4.9.0/default.yaml* >> >> --- >> wso2::dep_sync : >> enabled : true >> svn : >> url : http://rajkumar.com/repos/ >> >> >> *Native* hash merge would return the following; >> >> { >> "enabled" =>true, >> "auto_checkout" =>true, >> "auto_commit" =>false, >> "repository_type" =>"svn", >> "svn" => { >> "url" =>"http://rajkumar.com/repos/"; >> } >> } >> >> *Deeper* hash merge would return the following; >> >> { >> "enabled" =>true, >> "auto_checkout" =>true, >> "auto_commit" =>false, >> "repository_type" =>"svn", >> "svn" => { >> "url" =>"http://rajkumar.com/repos/";, >> "user" =>"username", >> "password" =>"password", >> "append_tenant_id" =>true >> } >> } >> >> >> If we use *Native* hash merging, we need to copy the complete nested >> hash ("svn" in above example) and override it. If we use *Deeper* hash >> merging, we can copy only a part of a nested hash and override it. As you >> can see, *Deeper* hash merge reduces data duplication. >> >> Thoughts please. >> >> Thanks, >> Raj. >> >> -- >> Rajkumar Rajaratnam >> Committer & PMC Member, Apache Stratos >> Software Engineer, WSO2 >> >> Mobile : +94777568639 >> Blog : rajkumarr.com >> > > > > -- > Akila Ravihansa Perera > WSO2 Inc.; http://wso2.com/ > > Blog: http://ravihansa3000.blogspot.com > -- Rajkumar Rajaratnam Committer & PMC Member, Apache Stratos Software Engineer, WSO2 Mobile : +94777568639 Blog : rajkumarr.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
