On Oct 31, 2010, at 11:18 PM, Daniel Pittman wrote:
> 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";
To me this says, add the strings together then use that as the source. I would
assume "add" means concatenate which means puppet would look for a file at:
protocol: puppet
path: "foo/barhttp://example.com/data";
So this doesn't work for me.
Also, this requires changing the grammar of he puppet parser which I think
shouldn't be done to fix one resource.
> 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")
The erb protocol stuff in here sounds to me like
http://projects.puppetlabs.com/issues/4920 which is very hard to do for
technical reasons. It's mostly because the variables used in the erb file are
not sent to the file server.
Note: The template() function is executed on the server when the manifest is
compiled.
On 10/30/2010 11:45 AM, Nigel Kersten wrote:
> http://projects.puppetlabs.com/issues/5158
>The source parameter, file function and template function all can take an
>array. For source/file, the first file that exists will be used. For the
>template function, we concatenate the templates instead.
>The file function takes fully qualified paths only. The template function
>takes fully qualified paths, or dereferences relative paths as follows.
>‘foo/bar.erb’ –> modules/foo/templates/bar.erb
>The latter problem is relatively easily solved, particularly if we implement
>#4885
>We are going to have to break backwards compatibility to solve the first
>problem however.
But you don't with my earlier suggestion quoted here:
On Oct 30, 2010, at 9:46 AM, Patrick 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.
>
>
> I also think the inconsistencies between "file()" and "template()" should be
> addressed, but this would simplify it.
This only changes the provider. Most of the suggestions I've heard change the
server and the language. I think this also keeps full backward compatibility.
(If it doesn't, please tell me) You say you don't want to add another
parameter, but adding another parameter is better than hacking the whole
language for one resource.
Also, having the provider parse very complicated input causes a lot of
confusion and bugs. (If you don't believe this, look at the Augeas provider
and it's quoting nightmare.) This way also doesn't reserve any characters in
the source string. Instead it uses the existing parser to handle (almost) all
the parsing.
--
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.
