Puppet users - Jan 2012 - I am looking to try to mixing sounrce and content in a file instance

Let''s start with this:

class whatever ( $myType=''other'' ) {
    file { "some-config-file":
        ...
        content => $myType ? {
            ''this''  =>
template("whatever/this.erb"),
            ''that''  =>
template("whatever/that.erb"),
            ''other'' =>
template("whatever/other.erb"),
            default => template("whatever/default.erb"),
        }
        ...
    }
}

I think I have all the cases covered my the "myType" parameter, but I
would REALLY like to be able to mix this with the multiple source syntax:

        source => [
            "puppet:///modules/whatever/${fqdn}-config-file",
            "puppet:///modules/whatever/default.config-file",
        ],

into something like this :

        source => [
            "puppet:///modules/whatever/${fqdn}-config-file",
            content => $myType ? {
                ''this''  =>
template("whatever/this.erb"),
                ''that''  =>
template("whatever/that.erb"),
                ''other'' =>
template("whatever/other.erb"),
                default => template("whatever/default.erb"),
            }
        ],

So that I can override the type-driven template with a flat file.

I am trying to design flexibility, and I am finding a "conflict of
purpose" between the source snd content metaparameters.
 
“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

On 01/10/2012 07:05 PM, Dan White wrote:
> I am trying to design flexibility, and I am finding a "conflict of
purpose" between the source snd content metaparameters.
is there a practical use case that actually requires that much
"flexibility"?

In the design scheme you''ve sketched, I would assume that there is a
specific $myType value that should have your resource rely on a list of
source URLs. Am I wrong?

If not, you''d need to change the manifest layout (if you''re
not wrapping
the file {} type in a defined type, you should definitely start doing
so) and this should be quite possible.

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks for responding, Felix

----- Felix Frank <felix.frank@alumni.tu-berlin.de>
wrote:
> Hi,
> 
> On 01/10/2012 07:05 PM, Dan White wrote:
> > I am trying to design flexibility, and I am finding a "conflict
of purpose" between the source snd content metaparameters.
> 
> is there a practical use case that actually requires that much
> "flexibility"?
It could be overkill, but I would rather have too much than too little.
One motivation is that a group of admins will be maintaining this eventually.
This approach appeals to me because it only requires manipulation of files
rather than messing with manifests/nodes/definitions.  Does that make sense ?

Could we talk about how I might implement this rather than the validity of the
use case ?
> In the design scheme you''ve sketched, I would assume that there is
a
> specific $myType value that should have your resource rely on a list of
> source URLs. Am I wrong?
Not really.  I expect the templates (one for each $myType variation/value) will
cover 99% of the cases.
I am the kind of guy to sweat over that last 1%  :)
> If not, you''d need to change the manifest layout (if
you''re not wrapping
> the file {} type in a defined type, you should definitely start doing
> so) and this should be quite possible.
At this point in my system design, this only applies to the one class, so I do
not see the advantage of wrapping it in a define.

If I find I need to re-use this recipe, a define wrapper makes sense, but I need
to make it work first.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Jan 11, 2012 at 7:49 AM, Dan White <ygor@comcast.net>
wrote:
> Thanks for responding, Felix
>
> ----- Felix Frank <felix.frank@alumni.tu-berlin.de> wrote:
>> Hi,
>>
>> On 01/10/2012 07:05 PM, Dan White wrote:
>> > I am trying to design flexibility, and I am finding a
"conflict of purpose" between the source snd content metaparameters.
>>
>> is there a practical use case that actually requires that much
>> "flexibility"?
>
> It could be overkill, but I would rather have too much than too little.
> One motivation is that a group of admins will be maintaining this
eventually.
> This approach appeals to me because it only requires manipulation of files
rather than messing with manifests/nodes/definitions.  Does that make sense ?
You can accept the source as a parameter and undef content as
necessary. content can simply be template(" extlookup/hiera with an
csv, yaml, or one of hiera''s pluggable backend. You can maintain the
ease of use and the flexibility you need here with a bit more
transparency.
> Could we talk about how I might implement this rather than the validity of
the use case ?
If you are trying to make this magically happen if you place the file
on the module files dir. You can write a custom ruby function using
File.exists? to verify if the file present to determine whether to use
the source or content attribute. This gets complicated if you have
multiple environment and module path. Puppet::Module.find(mod_name,
environment) is an internal API, but might be useful if you *really*
want to explore this path.

Nan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.