On Sat, Oct 30, 2010 at 1:55 PM, Patrick <kc7...@gmail.com> wrote:
>
> 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?
That would be because I said "array" instead of "multiple arguments",
which is what I meant, but after sketching it out, I don't see any
significant advantage over your suggestion of {source,content}_concat.
>>> 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.
We can do that as far as making template() and file() behave the same
way, but we can't ignore the functions altogether, as the
inconsistency between template() and source => is the major problem
here.
We don't have to rush to find a solution. This would be a big change
that we wouldn't push out in a point release.
--
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.
