David Schmitt <da...@dasz.at> writes:
> On 6/7/2010 3:08 AM, Daniel Pittman wrote:
>> Luke Kanies<l...@puppetlabs.com> writes:
>
[...]
>> 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?
>
> No. This could look like this:
Did I mention that stanza is repeated once per public address? ...but,
yeah, it can be forced to work together with the concat module or so.
(I think I noted that before: building an on-client templating system and
using that, or the current 'collect on puppetmaster, read in templates'
approach, both work — but are essentially work-arounds to filling an array
with the details I need, IMO.)
[...]
>> 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.
>
> Using the R.I.Pienaar's concat module you can manage the file on a
> chunk-by-chunk basis. If you use augeas, you can manage the file as
> finegrained as allowed by the available lenses.
*nod* For what it is worth, aside the complexities that can come creeping out
of the woodwork, these also scare me a bit:
concat works reasonably well, but depends no multiple fragments scattered over
multiple systems, and storeconfigs, which makes for two problems:
One, we now have anything up to two hours for an update to propagate, as
puppet needs to run on the "source" node /and/ the "target" node. That
hurts a bit, although tools like mcollective promise to make it easier.
Two, there is no one place to see the configuration structure. This makes it
much harder to visualize the effect of changes and the overall structure.
So far my staff and I have made that work, but I fully expect to have an issue
eventually where concat builds something wrong because we didn't see the
cross-check bits.
Augeus I don't want to touch: I learned the lesson, years ago with cfengine,
that trying to edit files in place was a great way to give yourself job
security: things would break so often that you would /always/ have something
broken to fix. ;)
Plus, writing Augeus code to edit a configuration file without messing it up
is an awful lot of work even for fairly trivial files; I would frankly rather
write ruby code.
>>> 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...
>
> Both concat and augeas do work without using ruby, although both do have
> their specific limitations.
...and those limitations are what bothers me about 'em. :)
Well, that, and the sense that this is a serious mismatch between my mental
model of how the systems (eg: config files, etc) work and how puppet models
them.
On which topic: I can see I might be wrong about this approach, and maybe
these tools are better than just asking for the facts I need, when I need
them, from the authoritative source of that data.
I just ... don't think so. In fifteen years of wrangling systems and building
software it has *never* been the right answer to proxy data through a
secondary source if you can get it from the master source, and these other
tools feel very much like doing that.
Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +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 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.
