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) > 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 :) > > -- > 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.
