Ohad Levy <[email protected]> writes: I don't think you have an apology to make: this is, indeed, a valuable thing to note in the context of the thread.
If this doesn't look like landing upstream in a suitable time-frame I will probably investigate writing my own little lookup tool that collates facts from all hosts and makes them available through something akin to the interface I gave. ...or, maybe roll out Foreman, but it would be mostly unused since we have other approaches to most of what it does. > 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]. For more options, visit this group >> at http://groups.google.com/group/puppet-dev?hl= en. >> -- ✣ 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.
