Luke Kanies <[email protected]> writes:
> On Jun 2, 2010, at 6:26 PM, Daniel Pittman wrote:
>> Luke Kanies <[email protected]> writes:
>>> On May 28, 2010, at 4:46 AM, Daniel Pittman wrote:
>>>> Luke Kanies <[email protected]> writes:
[...]
>>>> eg: "give me an array of fqdn facts for hosts including example::service"
>>>>
>>>> I hit that when I run into trying to build multi-system services, for
>>>> availability or scalability, but questions of this sort are relatively
>>>> common in the user list too.
>>>
>>> This is a pretty different use case, but it's one I'm interested in
>>> solving, also. However, I want to make sure it's not just a case of 'make
>>> a database call and stick the results in an array'. You say you're
>>> banging your own drum here - do you solve this now?
>>
>> Sorry, that was a poor choice of words. I meant "agitating for a solution
>> to my problem, which is similar-but-not-identical to the one being
>> discussed."
[...]
> That's a different thing I've been trying to characterise, but like you say,
> it's not quite external data.
*nod* It is certainly external to the current node, but the backing store is
the information that puppet itself already holds about the target node.
> How would you like this interface to work internally?
>
> That is, what kinds of things do you need to be able to specify, and how
> would you like to specify them?
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
Let me start with the data I want to get out of it, first:
The simplest version — the 80, or even 90, percent case — is covered by
"give me an array containing fact X of hosts matching criteria Y and Z"
eg: ['example1.fqdn', 'example2.fqdn']
Almost everything else is covered by "give me a hash containing facts (or
maybe puppet variables) X, Y, and Z of hosts matching criteria A, B, and
C".[1]
eg: { example1.fqdn => { X => 1, Y => 2, Z => 3 },
example2.fqdn => { X => 9, Y => 8, Z => 7 } }
...or an array of hashes, each hash containing only what facts were requested,
because I can always ask for 'hostname' or 'fqdn' if I need it.
In terms of how to express this? I really don't care that much. My personal
bias, in language design, is away from syntax[2], so this probably reflects
that:
All I need is to specify the data I want back, and the hosts to match:
get_node_facts('hostname', 'tag == "mega" and domain != "all-but-this.com"')
=> ['example1', 'example2']
get_node_facts(['hostname', 'ipaddress'], 'memory > 2000')
=> [{ hostname => 'example1', ipaddress => '192.168.1.1' }]
# ...or whatever the multiple-value return syntax ends up as. :)
Looking at the existing syntax, it could maybe be something like this:
$data = [[ hostname, ipaddress | tag == "mega" and memory > 2000 ]]
That preserves something of the flavour of the current "collect" stuff, which
is more or less what this is ... just fetching in data, rather than instances
of types.
Does that answer your question? I can certainly work up a couple of
real-world use cases for the stuff if you want.
Daniel
Footnotes:
[1] I think. I suspect that we actually need a bit more work with the
simplest version, and hashes in the language, to work out how it best
fits together in practice.
[2] It comes from being an old Lisp user, I guess, since I look at most
syntax as papering over the lack of a real ability to walk the AST inside
the language coherently. :)
--
✣ 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.
