Nigel Kersten <[email protected]> writes:
> ----------------------- Ticket description ---------------
>
> We have four main ways we can specify file content in a file resource.
>
> The source parameter
> The content parameter
> The file function
> The template function
[...]
> Here's a terrible suggestion that hopefully inspires a better one. An array
> indicates multi-select logic, separation with a colon means concatenate.
That is terrible, not least because it makes use of a valid filename component
that some platforms (*cough* Macintosh *cough*) have used as a vital part of
their path descriptions, and others use routinely.
Hint: /etc/environment/default-path and content is now gonna suck. :)
> 1a. Use the first source that exists.
[...]
> Is this so unsatisfactory that we need to add more parameters?
I think it could be satisfactory with only a tiny change that will *also*
solve another end-user problem we recently saw on the list:
file { "/etc/environment/default-path":
content => "/bin:/usr/bin:/usr/local/bin" + $more_path
}
source => "puppet:///foo/bar" + "http://example.com/data";
Oh, and this just works(tm):
source => ["puppet:///foo/bar.${fqdn}", "puppet:///foo/bar"] +
# OK, now I am just makin' stuff up at random. ;)
["erb:///foo/bar.$fqdn.erb", "template"///foo/bar.erb"] +
# ...or is that actually nicer than this API change?
# (selection, not concatenation)
template("foo/bar.$fqdn.erb", "foo/bar.erb")
Other string concatenation character choices would work, but perhaps would be
suboptimal from a being-consistent-with-Ruby point of view, if that matters.
(Also, functions, but this is likely to be common enough to justify an
operator in the circumstances.)[1]
The internal implementation may be complicated by this, somewhat, but a
sufficiently smart implementation should be possible that makes it just
work(tm) as the use would expect in the long term.[2]
This also, incidentally, fixes the implicit wish from a recent poster who
wanted to perform a lookup on a log filename based on a set of concatenated
values or so. (Actually, I think he wanted interpolated variable names, but
whatever. Maybe it wasn't relevant after all.)
> What if we pluralized for the concatenation with "sources" and "contents" ?
I agree with other posters that the distinction is accurate, but probably
error-prone; it would be easy to miss that when reviewing code, or have people
wonder if it was just a typo and have their manifests fail...
[...]
> Alternatively, do we really need to fix this? I think we do, as consistency
> matters a lot to me, but maybe I'm on my own here?
No, I think it does improve things measurably to make this consistent and
predictable. Nothing makes it harder to use a language than utterly unbounded
complexity explosions, but this sort of inconsistency comes a close second.
Daniel
Footnotes:
[1] ...or does that cause a conflict between math and concatenation when we
say something like 'if $x + $y > 12 { ... }' then?
[2] Specifically, I can see a potential conflict between the concatenation
operator and the idea of fetching HTTP URLs rather than just puppet://
ones, based on when that fetch happens - master or client.
Which is a worry that requires puppet gaining the ability to fetch
arbitrary content anyway; without that added there isn't much new
complexity here.
--
✣ 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 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.
