On Wednesday, July 8, 2015 at 10:57:44 AM UTC-5, DJ wrote: > > Hello, > > i was reading this doc " > http://garylarizza.com/blog/2014/10/24/puppet-workflows-4-using-hiera-in-anger"; > > which says it's not good idea to use Hiera auto binding feature, can you > guys suggest if you are using this feature and you have noticed any > performance issues or any issues related to not able to find from where > data is coming? > > In principle, you can disable automated data binding altogether in your master's configuration, but I've never heard of anyone actually doing so, and I'm not confident that it wouldn't cause breakage. Alternatively, you can use the resource-like class declaration syntax and provide a value for every class parameter, for every single class declaration. Even if that were feasible, it would be poor practice, making your manifest set brittle and difficult to maintain, because if ever you declare a class via the resource-like syntax, that must be the first declaration of that class that Puppet evaluates. As a general rule, therefore, you should avoid resource-like class declarations, except possibly for classes to -- carefully -- declare private classes of their own modules. Automated data binding is the feature that rescues parameterized classes -- without it they are a misfeature.
Gary makes good points, however: all those lookups for data binding can be costly in the aggregate. That cost depends on a lot of factors, among them - the number of levels in your hierarchy, and the density of data in your higher-priority levels - the number of parameters to which you bind data - the hiera back-end(s) you use Note in particular that where you do not provide a value for a class parameter in any way (an extremely common case in most environments), Hiera will look for a value in every single level of your hierarchy before it gives up. I don't think Gary's point was that you should try to avoid external data bindings altogether. You should, however, limit the number of levels in your hierarchy, and you should use the most efficient back-ends you can (those that decrypt data for you are more expensive than others; some of them *much* more expensive). To the extent that you're at liberty to control the classes and modules you use, consider also favoring those with fewer class parameters. Module design practice over the last few years has tended to go in the direction of providing large numbers of class parameters, especially on modules' public classes, to make them as adaptable as possible. Although adaptability is great, in most cases, folks use only a small subset of those parameters in any given catalog, and each parameter has a run-time cost even when it is not used. Especially when it is not used. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c1582438-de30-491d-858d-075b966cc86c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
