Luke Kanies <[email protected]> writes:
> On Jun 6, 2010, at 6:08 PM, Daniel Pittman wrote:
>> 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
[...]
>> 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
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.
> 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. :)
>>> 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.
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.
