On Jun 7, 2010, at 7:51 PM, Daniel Pittman wrote:
Luke Kanies <[email protected]> writes:
[...]
Hmm. So it sounds almost like if I gave you a compromise solution,
you'd be
happy:
1) Use storeconfigs for passing data between hosts
2) Provide array-collection for filling in templates
Yup. Being able to export/import resources fixed a lot of what I
need, and
this would probably cover 80 percent or more of what remains. At
that point
our configuration would be mostly nice, without any "work-around"
left.
:)
E.g., something like this:
# load balanced service
define balance($port, $address) {
# completely empty - just for data transfer
}
class something {
....
@@balance { something: port => 1234, address => $ipaddress }
}
# load balancer
class load-balancer {
addresses = Balance <<| name == something |>>.address
file { "/my/template": ... }
}
That is, everything looks the same in storeconfigs, but you can
easily sort it
back to data if you need to for generating stuff.
*nod* That would do what I needed. It would even, I think,
generalize back
to fetching all the data once the puppet language has a 'hash' type,
by
dropping the postfix '.whatever', and then returning the arguments
to the
define or so.
2.6 has hashes.
Mind you, I'm not exactly fond of this, but I don't exactly hate
it, either.
I've been suspecting for a while that it's a liability not being
able to
access resource attributes, especially as a set.
*nod* I would actually be tempted to have some syntax sugar over
the top of
that, even if that was the implementation underneath, and I suspect
that is
more or less the same ... taste reasons. :)
What kind of syntactic sugar?
I don't think this directly translates to hashes, partially because we
still don't have iteration.
I'd love to see a simple syntax for turning the attributes from a
subset of resources into an array. What I recommended is all I've
been able to come up with.
I am open to adding support for pulling attributes from the
database in
general, I just don't think that's actually the right long-term
answer.
Well, I don't really care how this works in the end — I think that
the
current model where you can't define composed resources without
Ruby is
nasty, but I am not sure anyone (myself included) has a better
model, right
now...
Do you mean you can't create concat-like resources without using
ruby, or
something else? I feel like I'm missing something.
...well, without using Ruby, or building it on the client, but more
or less,
yeah. It hits when I need to manage a configuration file that has
(dynamic)
data from more than one source, and where the tool doesn't support an
'include' statement.
So, pretty much what we are talking about above, when you get right
down to
it. Plus, obviously, my relative distaste for the concat module as a
solution, even if it does work to get the job done.
So...
I don't really advertise it, but it's wicked simple to create an empty
define (as above) and then write a function that collects a bunch of
resources and does something random with them:
define foo($something) {}
$array = collect_from_resources(foo, something)
Then just:
Puppet::Parser::Functions.newfunction(:collect_from_resources) do |args|
type = args.shift
param = args.shift
catalog.vertices.find_all { |resource|
resource.type.to_s == type.to_s
}.collect do |res|
res[param]
}
end
Or something like that. :)
So basically, we can do what you want, but you don't *have* to wait
for us. :)
And if that pseudo-code doens't work (I assume it doesn't) ping me and
I'm happy to walk through it.
--
Levy's Law:
The truth is always more interesting than your preconception of
what it might be.
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
