On Nov 1, 2010, at 7:31 AM, Nigel Kersten wrote:
> On Mon, Nov 1, 2010 at 1:21 AM, Patrick <[email protected]> wrote:
> I really don't think we can deprecate 'content' altogether, as while
> we're here trying to decide how to make these various chunks of
> functionality consistent, we also have to keep in mind the common use
> case of simply specifying 'content' as a string.
>
> Do you really want to deprecate 'content' for such cases and force
> people into using 'content_concat' ?
I'm going with jcbollinger's solution instead, but content_concat would have
done the same thing when passed one argument as content.
On Nov 1, 2010, at 8:28 AM, jcbollinger wrote:
> 1) Why add a new property "content_concat" when equivalent
> functionality could be made more broadly available by adding add a
> string concatenation function or operator by which to compose the
> value from its constituent pieces? E.g.:
>
> content => concat("# Standard Header\n", $my_content_piece1,
> inline_template('<%= ... %>'))
>
> No new parameter and no deprecation is needed, and there can be 100%
> backwards compatibility with respect to this parameter.
>
> 2) If there is concatenation to be done, then
> should it not be done on the puppetmaster? Among other things, only
> that way can a checksum be computed. Checksumming the individual
> pieces doesn't work because the client does not have separate pieces
> to check. If, then, the puppetmaster is going to compose pieces and
> checksum them, why should it not serve the composed result? And in
> that case, what would differentiate the source_concat property from
> the content (or content_concat) property?
I had totally missed that problem.
> To sum up:
>
> Resolving the perceived consistency issue can be done without any
> change to the File resource. It is sufficient to
>
> a) Fix the relative path problem for the file() function, and
> b) add a string concatentation function, and
> c) deprecate passing multiple arguments to template(), prefering
> instead applying the new conatentation function to several single-
> argument invocations of template().
>
> This approach is 100% backwards-compatible, inasmuch as deprecation of
> multiple arguments to template() does not imply removal of that
> feature. Because the new features would all be in functions, they
> would be available everywhere in manifests that functions can be
> invoked, not just in File resources. Furthermore, the new mechanism
> for concatenating template results would be both more expressive than
> the old and, because of its reliance on a general-purpose function,
> more broadly consistent than just with file() and File/source.
+1
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" 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-users?hl=en.
