)]}'
{"deployment/puppet/osnailyfacter/modular/hiera.pp":[{"author":{"_account_id":9387,"name":"Aleksandr Didenko","email":"adidenko@mirantis.com","username":"AD"},"change_message_id":"22246dc688850b2f6b0e7e12dce138215527a903","unresolved":false,"context_lines":[{"line_number":16,"context_line":":backends:"},{"line_number":17,"context_line":"  - yaml"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":":hierarchy:"},{"line_number":20,"context_line":"\u003c% @data.each do |name| -%\u003e"},{"line_number":21,"context_line":"  - \u003c%\u003d name %\u003e"},{"line_number":22,"context_line":"\u003c% end -%\u003e"}],"source_content_type":"text/x-puppet","patch_set":2,"id":"3a961159_c5554e1f","line":19,"updated":"2015-01-13 13:39:10.000000000","message":"We need a better hierarchy that would allow module developers or operations teams to override or add new settings needed by manifests. I would add something like this into $data array or right here before \"data.each\" block:\n\n - override/class/%{calling_class}\n - override/module/%{calling_module}\n - class/%{calling_class}\n - module/%{calling_module}\n\nSo with such hierarchy \"/etc/hiera/class/\" and \"/etc/hiera/module/\" directories could be used by module developers (including us) to ship/deploy hiera settings along with manifests.\n\"/etc/hiera/override/class/\" and \"/etc/hiera/override/module/\" could be used by operations to override some settings or add new ones.","commit_id":"dfdf49ec504e8df445ca5663e48c1cab8c4b3f06"},{"author":{"_account_id":9387,"name":"Aleksandr Didenko","email":"adidenko@mirantis.com","username":"AD"},"change_message_id":"7f08b64f4bc1a9d4a94ae64d3625be03fb09507a","unresolved":false,"context_lines":[{"line_number":16,"context_line":":backends:"},{"line_number":17,"context_line":"  - yaml"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":":hierarchy:"},{"line_number":20,"context_line":"\u003c% @data.each do |name| -%\u003e"},{"line_number":21,"context_line":"  - \u003c%\u003d name %\u003e"},{"line_number":22,"context_line":"\u003c% end -%\u003e"}],"source_content_type":"text/x-puppet","patch_set":2,"id":"3a961159_90c1c283","line":19,"in_reply_to":"3a961159_c5554e1f","updated":"2015-01-13 14:02:22.000000000","message":"Or even something like this:\n\n - override/node/%{::fqdn}\n - override/class/%{calling_class}\n - override/module/%{calling_module}\n - override/common\n - class/%{calling_class}\n - module/%{calling_module}\n\nSo  files like \"/etc/hiera/override/node/node-1.local.int.yaml\" could be used to provide node-dependent settings; \"/etc/hiera/override/common.yaml\" common file (not dependant on module/class names). Etc.","commit_id":"dfdf49ec504e8df445ca5663e48c1cab8c4b3f06"}]}