On Oct 30, 2010, at 9:52 AM, Nigel Kersten wrote: > On Sat, Oct 30, 2010 at 9:46 AM, Patrick <kc7...@gmail.com> wrote: >> >> On Oct 30, 2010, at 8:45 AM, Nigel Kersten wrote: >> >>> http://projects.puppetlabs.com/issues/5158 >>> >>> ----------------------- 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 >>> >>> These behave inconsistently in the following ways. >>> >>> 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. >>> >>> My feeling is that more people make use of the multi-select logic in >>> the source parameter/file function than make use of the concatenation >>> of the template function. >>> ----------------------- >>> >>> I'm opening this up for discussion here on the user list as we need to >>> all agree whether it's worth chasing consistency here at the cost of >>> breaking backwards compatibility. >>> >>> It appears that people use both the concatenation and multi-select >>> logic. How can we provide both bits of functionality for all these >>> methods? >>> >>> Here's a terrible suggestion that hopefully inspires a better one. >>> An array indicates multi-select logic, separation with a colon means >>> concatenate. >>> >>> 1a. Use the first source that exists. >>> >>> file { "/tmp/somefile": >>> source => ["puppet:///modules/foo/somefile.$hostname", >>> "puppet:///modules/foo/somefile.default",] >>> } >>> >>> file { "/tmp/somefile": >>> content => template("foo/somefile.$hostname.erb", >>> "foo/somefile.default.erb"), >>> } >>> >>> 1b. Concatenate multiple objects >>> >>> file { "/tmp/somefile": >>> source => >>> "puppet:///modules/foo/somefile.$hostname:puppet:///modules/foo/somefile.default", >>> } >>> >>> file { "/tmp/somefile": >>> content => template("foo/somefile.$hostname.erb:foo/somefile.default.erb"), >>> } >>> >>> Is this so unsatisfactory that we need to add more parameters? What if >>> we pluralized for the concatenation with "sources" and "contents" ? >>> >>> 2b. New parameter for concatenation. >>> >>> file { "/tmp/somefile": >>> sources => ["puppet:///modules/foo/somefile.$hostname", >>> "puppet:///modules/foo/somefile.default",] >>> } >>> >>> file { "/tmp/somefile": >>> contents => [template("foo/somefile.$hostname.erb", >>> template("foo/somefile.default.erb")], >>> } >>> >>> 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? >> >> 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. > > Would it be better if we could make the template function be aware of > a boolean parameter "concatenate" that changed the behavior when an > array is passed to it? (and we do the same thing for source)
Sorry but you totally lost me. Does the template() function even take an array now? >> I also think the inconsistencies between "file()" and "template()" should be >> addressed, but this would simplify it. > > Absolutely. I would prefer to leave the existing behavior around for a > while and we implement http://projects.puppetlabs.com/issues/4885 > which I think was your suggestion anyway :) Mostly. I was just saying, lets brainstorm about the parameters here and worry about the functions somewhere else. > >> >> -- >> 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. >> >> > > > > -- > Nigel Kersten - Puppet Labs - http://www.puppetlabs.com > > -- > 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. > -- 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.
