seph,

You are making a couple of classic mistakes here. For one, thinking of
definitions as "functions" can only end in tears. Definitions are just
ways of abstracting a collection of resources into a single resource.
The second mistake you make is in thinking procedurally. Puppet's
model is declarative, not procedural. You don't loop through an array
and add each item to a keystore. You declare a keystore. You declare
keys, with parameters saying which stores they should be part of.
That's the way you should model this problem to avoid fighting the
tool.

Since I have a hard time understanding precisely what you are trying
to accomplish, I can't be more specific. But I can advise you take a
step back, remind yourself that definitions are not functions (you
don't "call" a gpg::keystore, you "declare" it, and the terminology is
very important in understanding the model), and then try to rethink
the problem in terms of resources.

--Paul

On Thu, Jul 30, 2009 at 9:51 AM, seph<s...@directionless.org> wrote:
>
> Inspired by the recent thread titled "Array input of dirs, ensuring
> their existence" I thought I'd write up the problem I'm running into. I
> was chatting on irc about it, I don't think puppet has a clean solution.
>
> Like the other poster, I'm defining an object that takes an array. In
> my case, I'm defining gpg keystore, which can contain a number of
> keys. (actually part of a larger svn repository object) It would be
> called something like:
>
>   gpg::keystore{ "/svn/repo/conf/pubring.gpg":
>     keys => ["XXXXXX", "YYYYYYY"],
>   }
>
> The obvious way to deal with that array, is to use a require, or to have
> the definition directly call the key function.
>
>   gpg::addkey{ $keys:
>     store => $keystore,  #as passed in as $name
>   }
>
> But, this requires that the resources be named with the keyid. Which
> fails when I have multiple keystores -- they can't both define
> gpg::addkey["XXXXX"].
>
> It's hard to see a nice solution to this. If puppet supported
> for loops, I could do something. Or if I could pass some kind of
> multidimensional bit in the $name array expansion.
>
> I can get some of it, by inverting the logic. So instead of defining
> keystores with key attributes, I instead define keys and the locations
> they should get added to. But I find that much harder to maintain, and
> it scales differently.
>
> Depending on the details, using inline_template can get part way. But
> it's a lot of extra complexity, and I don't think it solves all
> problems.
>
> I think I'll probably just rethink my setup, so I only have 1 keystore
> per machine, but I'm not very pleased with that. Anyone have any
> better suggestion? Any chance at getting better puppet support for
> this sort of array handling?
>
> seph
>
> >
>



-- 
"My pants growl with the hunger of a thousand bubblebees. And it feels
like a Koala crapped a rainbow in my brain!" -MasterShakezula

--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to