On Thursday, May 15, 2014 9:46:40 AM UTC-5, Alessandro Franceschi wrote:
>
> Hallo everybody,
> I've tried to look around in the group for past discussions about this
> topic but haven't found any.
> If this has been already debated , please forgive me and point me to the
> right direction.
>
> I wonder what do you thing about a feature request to have data bindings
> also for defines' parameters.
>
I'm skeptical about their value. We already have data bindings for
classes, by which resource parameters can (indirectly) be injected, and I
am inclined to think that classes are the right level of abstraction. On
the other hand, we also have create_resources(), which already can give you
resource-level data binding if you want to use it that way.
I do not favor drawing distinctions between defined resource types and
native resource types. On that basis, I would argue for data binding
either for all resource types or for none, and against data binding for
only defined types.
I am concerned about the impact. It is already somewhat costly for Puppet
to evaluate data bindings for class parameters, and adding bindings for
resource parameters (even just for resources of defined types) will magnify
that. Note that the cost scales with the aggregate number of defined
parameters for all declared resources, independent whether any data are
actually bound. In fact, the cases were no data are bound are the most
costly, because hiera must then search the entire hierarchy.
> Naming is straightforward, a define like:
> apache::vhost { 'example.com': }
>
> could have its params looked in this namespace:
> apache::vhost::example.com::<parameter>
>
> My poor understanding of Puppet code points me to:
>
> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/resource.rb#L343
> and makes me guess that such a change should not be too difficult.
>
I agree, the change probably would not be difficult to implement -- just
costly. It might be interesting to have some data on what proportion of
invocations of that method follow the "return nil" branch, avoiding a
lookup. As a wild guess, I'll say at least 75% in a typical catalog
compilation run (maybe we can start a pool :-)). Even if it were only 25%,
though, that would translate into a 33% increase in the number of
(expensive) lookups.
> I see many wonderful use cases for such a feature and no apparent cons.
>
I see no particularly good use cases and several cons, but I'm prepared to
be amazed by your vision. Would you care to elaborate?
John
--
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/6a570826-d6af-425c-a1bb-20c29f181202%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
