On Jun 6, 2010, at 6:08 PM, Daniel Pittman wrote:
Luke Kanies <l...@puppetlabs.com> writes:
On Jun 4, 2010, at 1:19 AM, David Schmitt wrote:
On 6/4/2010 3:45 AM, Daniel Pittman wrote:
Well, my use case pretty much always comes down to "do something
for this
data about this host", and hasn't ever gotten more than two
levels deep:
backuppc::server needs a per-client configuration
per-client configuration needs this clients mount-points and
excludes
the load-balancer needs the hostname and ip of every app-server
Just as another "data point", I cover those things also with export/
collect, but do not need an ERB template, by actually creating the
needed
file fragments (usable for volcane's concat) on the source
hosts. Collection can then use the <<||>> query language to select
what's
needed, in my cases always by tag.
That approach has great flexibility, without the pain of accessing
the DB
myself.
To me, we need to be focusing on fixing Collection so it actually
works well
for this purpose. It sounds like most of Daniel Pittman's needs
would be
solved by better resource collection.
Well, maybe. One use case, which is pretty obvious, is our load
balancer
configuration, which needs to wind up looking like this:
virtual=10.17.0.1:80
<% appserver_addresses.each do |addr| -%>
real=<%= addr %>:80
<% end -%>
All I really need to do for this to work is collect the
'ipaddress_eth0' fact
from every node that imports the 'appserver' class into an array.
This model meets ... well, probably not all my needs, but plenty of
them.
The real problem, so far as I can see, with this and using resource
collection
is that unless your resource is a "fact" I *have* to go down to the
Ruby
level, right?
Specifically, as far as I know I can't define a "resource" inside
puppet that
is composed into another resource: the "real=1.2.3.4:80" line can't
be a
separate resource from the ldirectord.cf file that it is contained
within.
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
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.
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.
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.
--
Dawkins's Law of Adversarial Debate:
When two incompatible beliefs are advocated with equal intensity,
the truth does not lie half way between them.
---------------------------------------------------------------------
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 puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
