Puppet users - Sep 2013 - getting array of hostnames of clients

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

where I''ve got a nodetype fact which works fine for me.

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

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.

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:

require ''facter''
Facter.add("nodelist") do
  setcode do
    path="/tmp"
    if File.exists?(path) && File.directory?(path) && ! Dir[path
+
''/*''].empty?
    output = Facter::Util::Resolution.exec("/bin/cat 
/tmp/testnode*").split(''\n'').join('','')
    else
      output = "empty"
    end
    output
  end
end

but this isn''t getting anything in the fact at all, not even
"empty".
Running that cat command on the commandline returns exactly what I would 
expect.

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 each node I have this:
  @@file { "testnode-{$::fqdn}":
    ensure => file,
    path => "/tmp/testnode-$::fqdn.txt",
    mode => 640, owner => root,
    tag => ''testnodes'',
    content => "$::hostname
",
  }

On the puppetmaster node definition I have this:
  File <<| tag == "testnodes" |>>

  file { ''nodelist'':
    path => ''/tmp/nodelist'',
    content => "
$::nodelist
"
    }
}

and I was expecting a file /tmp/nodelist to contain the text from the fact 
$::nodelist but the file is empty.


So, sorry, but I have three questions:

1. why isn''t that curl getting the facts? Why is it getting this
NoMethod
error?
2. why isn''t that new nodelist fact working? If a fact has an error
where
does this get logged?
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.

 facter --version
1.7.2

puppet --version
3.2.4


-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

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?

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.

Or do you mean that you pass the command itself as a literal fact value, 
which the master executes locally to extract the result?  Again in that 
case the value is not a property of the node, so it doesn''t appear to
make
much sense to use a fact.  Also, it would be a serious security risk for 
the master to execute commands provided by clients.

 
> where I''ve got a nodetype fact which works fine for me.
>
> 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?

 
>
> 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.

 
>
> 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?

 
> require ''facter''
> Facter.add("nodelist") do
>   setcode do
>     path="/tmp"
>     if File.exists?(path) && File.directory?(path) && !
Dir[path +
> ''/*''].empty?
>     output = Facter::Util::Resolution.exec("/bin/cat 
>
/tmp/testnode*").split(''\n'').join('','')
>     else
>       output = "empty"
>     end
>     output
>   end
> end
>
> but this isn''t getting anything in the fact at all, not even
"empty".
> Running that cat command on the commandline returns exactly what I would 
> expect.
>

If you''re not getting the fact at all, even after you restart the agent
(though that should not be necessary), then I conclude that the fact has 
not been synced to the client.

 
>
> 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 each node I have this:
>   @@file { "testnode-{$::fqdn}":
>     ensure => file,
>     path => "/tmp/testnode-$::fqdn.txt",
>     mode => 640, owner => root,
>     tag => ''testnodes'',
>     content => "$::hostname
> ",
>   }
>
> On the puppetmaster node definition I have this:
>   File <<| tag == "testnodes" |>>
>
>   file { ''nodelist'':
>     path => ''/tmp/nodelist'',
>     content => "
> $::nodelist
> "
>     }
> }
>
> and I was expecting a file /tmp/nodelist to contain the text from the fact 
> $::nodelist but the file is empty.
>
>
   1. You are collecting the Files only on the master, therefore only the 
   master''s $::nodelist fact could provide the information you want.
   2. Facts are evaluated before catalog compilation, therefore even the 
   master''s $::nodelist fact would be perpetually one cycle behind.
   
 
>
> 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.

 
> 2. why isn''t that new nodelist fact working? If a fact has an
error where
> does this get logged?
>

See my discussion above for possibilities.  Any log output would show up in 
the agent''s log destination, which by default is the regular system
log.
On the agent.

 
> 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.
>
>
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?


John

-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

http://docs.puppetlabs.com/references/latest/configuration.html#reportdir gives
a list of certnames.

I use FQDN for my certname, so ... 


“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes) 

----- Original Message -----
From: "jcbollinger" <John.Bollinger@stJude.org> 
To: puppet-users@googlegroups.com 
Sent: Wednesday, September 11, 2013 10:50:59 AM 
Subject: [Puppet Users] Re: getting array of hostnames of clients 




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?

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.

Or do you mean that you pass the command itself as a literal fact value, which
the master executes locally to extract the result? Again in that case the value
is not a property of the node, so it doesn''t appear to make much sense
to use a fact. Also, it would be a serious security risk for the master to
execute commands provided by clients.


<blockquote>



where I''ve got a nodetype fact which works fine for me. 


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 

</blockquote>



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?


<blockquote>





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.
</blockquote>



Yuck. 


<blockquote>




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:



</blockquote>



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?


<blockquote>




require ''facter'' 

Facter.add("nodelist") do 
setcode do 
path="/tmp" 
if File.exists?(path) && File.directory?(path) && ! Dir[path +
''/*''].empty?
output = Facter::Util::Resolution.exec("/bin/cat
/tmp/testnode*").split(''\n'').join('','')
else 
output = "empty" 
end 
output 
end 
end 


but this isn''t getting anything in the fact at all, not even
"empty". Running that cat command on the commandline returns exactly
what I would expect.
</blockquote>



If you''re not getting the fact at all, even after you restart the agent
(though that should not be necessary), then I conclude that the fact has not
been synced to the client.


<blockquote>




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. 
</blockquote>



On which command line? You could have the fact installed on the master, but not
synced to clients.


<blockquote>




On each node I have this: 

@@file { "testnode-{$::fqdn}": 
ensure => file, 
path => "/tmp/testnode-$::fqdn.txt", 
mode => 640, owner => root, 
tag => ''testnodes'', 
content => "$::hostname 
", 
} 


On the puppetmaster node definition I have this: 

File <<| tag == "testnodes" |>> 



file { ''nodelist'': 
path => ''/tmp/nodelist'', 
content => " 
$::nodelist 
" 
} 
} 


and I was expecting a file /tmp/nodelist to contain the text from the fact
$::nodelist but the file is empty.


</blockquote>



    1. You are collecting the Files only on the master, therefore only the
master''s $::nodelist fact could provide the information you want.
    2. Facts are evaluated before catalog compilation, therefore even the
master''s $::nodelist fact would be perpetually one cycle behind.

<blockquote>





So, sorry, but I have three questions: 


1. why isn''t that curl getting the facts? Why is it getting this
NoMethod error?
</blockquote>



Beats me. It might help for you to explain more fully how you are using it, and
to present the curl output actually generated.


<blockquote>


2. why isn''t that new nodelist fact working? If a fact has an error
where does this get logged?
</blockquote>



See my discussion above for possibilities. Any log output would show up in the
agent''s log destination, which by default is the regular system log. On
the agent.


<blockquote>


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.


</blockquote>



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?


John 



-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com. 
Visit this group at http://groups.google.com/group/puppet-users . 
For more options, visit https://groups.google.com/groups/opt_out . 

-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, September 11, 2013 8:46:23 PM UTC-5, Steve Wray
wrote:
>
> 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.
>

Indeed you did.  I am struggling with your setup a bit because you are 
going about things in a very unorthodox way.

 
>  
>
>>
>>    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
>
>
Oh.  In that case, file a bug against Puppet about that.  Even if the REST 
service no longer supports your query, it should not fail in that way.

 
>
>
> 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.
>>
>>
>
Now that I understand better what you are doing, there are absolutely 
better ways, at the very least in that you should not be using a fact to 
get the data into the catalog compilation process.  If you want the master 
to compute the data, then the computation would be better done in a custom 
function, or even via the built-in generate() function.  That better fits 
the data''s node-independent nature (even though it contains information
about several nodes, taken as a whole it is not node-specific).  Also, that 
will allow the data to be used in catalogs other than the master''s
node''s
own.

 
> <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 am driving at is that it may be more consistent with Puppet, and 
easier, to take an approach that does not require you to assemble such an 
array in the first place.  The usual way of using exported resources 
involves nodes providing resources for other nodes to apply.  That can work 
in conjunction with the Concat module or similar to build config files from 
a collection of pieces contributed by many nodes.  One of your alternatives 
is to do something like that to manage your smokeping target config files, 
instead of using the smokeping::target definition you have now.

 
>
> 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. 
>
>
If you want to do it that way then I would suggest reading the docs for 
PuppetDB''s HTTP API: 
http://docs.puppetlabs.com/puppetdb/latest/api/index.html .  It appears to 
have support for something similar to what you were doing before.  To adapt 
one of the examples from the docs, for example, perhaps this would retrieve 
the data you want, if run on the master:

curl -G ''http://localhost:8080/v2/nodes'' --data-urlencode
''query=["=", ["fact", "nodetype"],
"testnode"]''

Again, that should not be executed via a custom fact, but rather by a custom
function.  Or you could just use generate() in your manifest to get the raw
output of that command, if that were useful to you.



John

-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.