I'll just add, since you didn't put the whole thread in, all of this is already possible with Foreman query interface today.
Ohad On Fri, Jun 4, 2010 at 9:45 AM, Daniel Pittman <[email protected]> wrote: > 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]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- 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.
