Luke Kanies <[email protected]> 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.
> 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...
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
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.
