oops, I though you sent it to puppet-users - sorry for the spam On Fri, Jun 4, 2010 at 10:13 AM, Ohad Levy <[email protected]> wrote:
> 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.
