On Wednesday, 11 September 2013 22:50:59 UTC+8, jcbollinger wrote: > > > On Wednesday, September 11, 2013 2:49:50 AM UTC-5, Steve Wray wrote: >> >> I need to get an array of hostnames of clients of the puppet server. >> >> There doesn't seem to be a simple way to do this so I've tried a few >> methods. >> >> I've tried a curl expression in a fact like this: >> >> curl -s -k -H "Accept: yaml" >> https://localhost:8140/production/facts_search/search?facts.nodetypet=testnodes >> >> > > In other words, this is intended to retrieve the desired information via > the master's REST API. I'm not quite making the connection here, however: > how is putting that expression into a fact supposed to achieve your result? >
It was returning a list of hostnames of nodes before I started using puppetdb, but only on the puppetmaster itself. Do you mean you have a custom fact that executes that command and parses > the YAML result to produce the desired array? That seems odd, because in > that case 'localhost' probably would not resolve to the correct machine (it > would be the client, not the master), and because the result is not a > property of the node. > Yes on the puppetmaster of course. > Now, this used to work but doesn't any more. Between it working and now >> I've changed to using puppetdb. I'm not sure if theres a connection. >> >> The error returned is: >> >> Caught NoMethodError: undefined method `<<' for nil:NilClass >> > > > There could be a connection. I have lately seen some evidence that > puppetdb may not reliably escape fact values when it stores them. That > would be a serious flaw, but I cannot confirm its existence. > > Alternatively, if you have also updated your master, then it may be that > the data returned by the REST call has changed in form or content. Do you > get what you expect if you run it from the command line? > I get the error when I run it from the commandline, after seeing it not work in the fact running the curl commandline was the first thing I tried. > The next thing I tried was to get each interesting node to create a file >> on the puppetmaster server. So I now have a bunch of files in /tmp/ with >> distinctive names which contain only the hostname of that puppet client. >> > > > Yuck. > Yuck indeed. But so far we haven't got any other way to get the list of nodes. I'm asking for a better solution. > I have a fact which is supposed to cat these together and, with luck, turn >> them into an array at some time. What I currently have is this: >> > > Facts are properties of target nodes, and their values are evaluated > there. Dropping a bunch of files on the master could allow the Puppet > agent to collect data from them into a fact when it runs on the Puppet > master server, but it cannot do anything for agents running on other > nodes. Do you need the information on nodes other than the master? > At this point in time the puppet master node will do but ultimately I need this list propagated to the smokeping server. What I am trying to avoid is hard-coding the list of smokeping slaves. Puppet configures the slaves themselves and it should be able to get a list of those slaves onto the smokeping server without me having to list them exhaustively and manually (and keep that list up to date). If I run facter on the commandline like this: >> FACTERLIB="/etc/puppet/modules/smokeping_prep/lib/facts" facter nodelist >> >> I get the list I expect. >> > > > On *which* command line? You could have the fact installed on the > master, but not synced to clients. > on the commandline on the puppet master of course, otherwise the FACTERLIB path wouldn't make any sense. The fact is being read on the puppet master node and supposedly going into that file but it isn't. I did say "On the puppetmaster node definition I have this:" and then the code thats supposed to put the fact into a file. > > 1. You are collecting the Files only on the master, therefore only the > master's $::nodelist fact could provide the information you want. > > Yes thats right. But it doesn't. > > 1. Facts are evaluated before catalog compilation, therefore even the > master's $::nodelist fact would be perpetually one cycle behind. > > I don't think thats a problem. > So, sorry, but I have three questions: >> >> 1. why isn't that curl getting the facts? Why is it getting this NoMethod >> error? >> > > > Beats me. It might help for you to explain more fully how you are using > it, and to present the curl output actually generated. > I'm running the curl command ON the puppet master itself and that IS the output actually generated, the error. Here it is again: Caught NoMethodError: undefined method `<<' for nil:NilClass 3. Is there an easier way to do what I want? An array of hostnames of > clients matching a fact which I can then pass to other Puppet commands. On > the face of it I'd think this was something many people would want to do. > In my case I want to generate a list of Smokeping slaves as a parameter for > Puppet-generated Smokeping targets. Ie Puppet already generates configs for > the targets and the slaves and I want to populate the target config with a > set of slaves. > > <quote sorry, google groups seems to have messed up the quoting at this point so your response appears as unquoted> There is probably an easier way, but it's very unclear what you actually do want. You are focusing very narrowly on getting an array of hostnames, but that is probably not the best vehicle to get you to your ultimate objective. Quite possibly exported resources would do the trick for you if used correctly. I have no familiarity with Smokeping, though, so you'll have to help me there. Are you building this from scratch, or using a third party module such as https://github.com/tobru/puppet-smokeping ? What ultimately needs to appear on the target node(s) (presumably contents of some file)? What declarations, specifically, do you want to be able to make in your Puppet manifests? </quote> The targets have puppet code like this: @@smokeping::target { $hostname: menu => $hostname, pagetitle => $hostname, hierarchy_level => 2, hierarchy_parent => 'PARENT', host => $fqdn, slaves => ['slave1','slave2','slave3','slave4','slave5'], } ultimately there will be about 70 slaves. Clearly as this is an exported resource the list of slaves has to be available to each target. What I want is that list to be generated from the slaves that have already been configured; puppet is creating them, puppet should know about them and puppet should be able to get this array generated. This seems harder than it should be and I don't see any built in way to do this; everything I've seen so far suggests that to do this is going to require some really ugly hack. I guess the 'cleanest' way I can think to do this is to generate Puppet code from an erb template and drop that into /etc/puppet/modules/mymodule/manifests. Self-modifying code, great :( Or can I use an exported resource to create an array? Or what? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
