David Schmitt <[email protected]> writes:
> On Tue, 28 Sep 2010 12:15:47 -0700, Nigel Kersten <[email protected]>
> wrote:
>
>> Have we been able to come up with any use cases other than packages where
>> combining offers a benefit?
>
> The nagios types seem to be reparsing/rewriting the target on every
> resource. Having them grouped and written out at once might reduce the
> overhead. I can imagine a provider implementation which prefetches the
> target and delays the write-out internally, but I'd rather not ;-)
> Especially since the nagios types have the additional problem of mixing
> multiple types within the same target.
>
> Having this in the "orchestration" layer and supported by a well-defined API
> on the type and provider level (having the grouping explicit and allow the
> implementation to provide a group_flush method), would make the flow much
> clearer and keep types/providers from second-guessing the required
> flush-barriers.
For what it is worth that "orchestration" layer sounds suspiciously like what
might be needed internally to implement part of my mental model for resources.
Specifically (and, as y'all have heard before), the case where you have a
configuration file that is composed of multiple independent components like,
say, an Apache configuration file with multiple sites, but without using
'include' to implement it.[1]
Just sayin'
Daniel
Why, yes, I might have my eye on things that make this easier to implement
tomorrow, indeed.
Footnotes:
[1] Usually, of course, in the form of something that has multiple
independent components, but upstream doesn't provide 'include', and where
you currently find the 'concat' module or something similar working
around the issue of modelling this naturally.
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
