On Friday, May 16, 2014 9:50:04 PM UTC+2, henrik lindberg wrote: > > On 2014-16-05 21:35, Alessandro Franceschi wrote: > > Andy, > > did this on a vagrant box with eyaml and file backends. > > The hierarchy has 7 levels. > > > > > Debug: PROFILE [apply] 2.3.2 Called hiera: took 0.0156 seconds > > > > If types on average have 10 parameters/properties, and you have 200 of > them, that means the overhead is something like 30 seconds for this > hierarchy. (Ballpark figure obviously) since it depends on where in the > hierarchy they are, and if they have values or not set in the manifests. >
Yes, I definitively see the perfomance problems here. Incidentally this should trigger an alarm for whoever abuses with the number of parameters in classes (me, included). I take the occasion (sorry for OT) to ask you an advice for what is my actual need, which made me ask for such a feature and which might be approached in an alternate way. I described in a previous post in this thread what I'd like to do. Basically have an in-module hiera datadir . An alternative approach to data bindings on defines + data in module can be to create a custom function that makes the hiera lookup on the module local data directory. I've seen that the hiera function accepts an optional parameter that defines an extra data source in hierarchy to add to the configured one. Can his be an array of datasources? Is it based only on the datadir configured in the local hiera.yaml? In this case the datadir should be in the module itself. Is is possible to set an alternative path for the hiera.yaml when calling the hiera function ? (A sort of data in modules, based on a function and not on data binding indirection as done in Rip's module). Any hint, also regarding totally different approaches for this problem would be very welcomed. > > Out of curiosity, why not use the Puppet Resource Default mechanism and > only lookup in hiera what you actually need and set those values as > defaults? Is it too limited for what you want to do? If so how? > Well, if we don't lookup values defined in resources defaults we can't override them. It might be limitating (and in the case of the tp module mentioned earlier, i would not make sense to have resource defaults). al > - henrik > > > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/a71e77b8-c0f9-4c23-b9f7-9ae032d4fb43%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
