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 -~----------~----~----~----~------~----~------~--~---