On Oct 30, 11:46 am, Patrick <kc7...@gmail.com> wrote:
> The best solution I can come up with is this.
>
> source - Unchanged because this is used so much. Tries each source in turn
> and uses the first one that works. Fails if none work.
> content - Deprecated but kept for backwards compatibility
> source_concat - Concatenates all the given sources and causes the resource to
> fail if any are missing.
> content_concat - behaves the same way as content does now and takes
> precedence over content.
>
> Throw an error if two or more are used at the same time, except allow content
> and content_concat to exist at the same time for backwards compatibility.
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) I'm not so keen on source_concat either, though I like it better
than content_concat. 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?
In short, I think the current "content" and "source" parameters both
work fine exactly as currently designed, and indeed, both are designed
as they are for good reason. Furthermore, I think it is nicely
consistent that once the relative path issue is fixed for file(),
content => file("foo", "bar")
will produce the same client-side content as
source => ["foo", 'bar"]
Consider now that it's template() that is the oddball here. Given a
concat() function as suggested above, however,
template("t1", "t2")
would be equivalent to
concat( template("t1"), template("t2") )
so how about resolving the perceived inconsistency by deprecating
passing multiple arguments to template()? The feature need not be
removed any time soon (indeed, it might never be removed), but the
replacement would be both more expressive and trivially consistent
with File/source and file().
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.
Regards,
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
