[Puppet Users] Re: Heria, Facts, and Puppet
I am using Puppet 2.7.21 open source version, and running on my mac. I
On Friday, July 26, 2013 8:34:13 AM UTC-7, GregC wrote:
What puppet master version are you running? I also seem to see this
bizarre behavior in 2.6.11 and no one at puppet labs has responded to this
hiera issue it just goes unanswered, I've also read that the catalog gets
compile in random order on each run prior to 2.7, this explains some weird
results i've seen in the past.
As stated earlier switch and put common last in the hiera.yaml file.
As a test try this. change yaml file like so:
:backends:
- yaml
:hierarchy:
- common
#- '%{env_name}'
:yaml:
:datadir: /var/lib/hiera/data
put the class or module info you have from your envXX.yaml file in the
common.yaml file.
If catalog run is successful then you are dealing with the weird hiera
bug. WOuld be interested to know your results, good luck.
On Thursday, July 25, 2013 1:49:56 PM UTC-4, Ellison Marks wrote:
Not sure exactly, but in general you want common to be searched last, as
hiera by default bails when it finds an answer, so your hierarchy in the
conf file is backwards. You'd want the env_name fact above common.
On Thursday, July 25, 2013 7:27:26 AM UTC-7, chengkai liang wrote:
So something doesn't look right for me when running puppet apply -e
'include ...' for looking heria via facter fact.
I have hiera configure as this,
:backends:
- yaml
:hierarchy:
- common
- '%{env_name}'
:yaml:
:datadir: /var/lib/hiera/data
and, a file envXX.yaml store in the datadir, and I can run *hiera xyz
env_name=envXX* to get the the value of abc associate with xyz.
Yet, if I export the value variable env_name by *export FACTER_env_name=
*envXX, and run:
*puppet apply -e 'include my_module
*
puppet will complaint that it can't find data store in envXX.yaml. From
the debug output,
debug: importing
'/Users/cliang/.puppet/modules/puppet_flux2_config/manifests/init.pp' in
environment production
debug: Automatically imported puppet_flux2_config from
puppet_flux2_config into production
debug: hiera(): Hiera YAML backend starting
debug: hiera(): Looking up host_header_url in YAML backend
debug: hiera(): Looking for data source common
Could not find data item host_header_url in any Hiera data file and no
default supplied at
/Users/cliang/.puppet/modules/puppet_flux2_config/manifests/init.pp:4 on
node m-mba.local
It seems that it stop looking right after common, while running with *hiera
xyz env_name=envXX* *--debug *shows,
DEBUG: Thu Jul 25 07:24:48 -0700 2013: Hiera YAML backend starting
DEBUG: Thu Jul 25 07:24:48 -0700 2013: Looking up host_header_url in
YAML backend
DEBUG: Thu Jul 25 07:24:48 -0700 2013: Looking for data source common
DEBUG: Thu Jul 25 07:24:48 -0700 2013: Looking for data source *envXX*
DEBUG: Thu Jul 25 07:24:48 -0700 2013: Found xyz in *envXX*
So why puppet apply won't look further into envXX.yaml file? Anybody
can help on this?
--
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+unsubscr...@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.
[Puppet Users] Re: How do I set global noop?
Sam,
You could make some changes to you site.pp and set some defaults like this
Exec {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
File {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Group {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Mount {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Package {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Service {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
User {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
. and more .
Make sure that all puppet types you use within you modules are covered in
the site.pp and have the noop = $::globalvars_noop added.
The final step is to set the topscope variable 'globalvars_noop' somewhere
(for example hiera, or Puppet console) and your node will be run with noop.
No need to touch any puppet config on the clients, and very easy to manage
:-)
Regards,
Rene vd Linden
Blog: https://www.rvanderlinden.net/wordpress
On Tuesday, July 23, 2013 1:29:24 AM UTC+2, Sam Morrison wrote:
I'm trying to set a global noop but it doesn't seem possible,
There are 2 bugs open about this which to me look pretty serious as the
expected behaviour isn't the case.
http://projects.puppetlabs.com/issues/21286
http://projects.puppetlabs.com/issues/6549
If anyone has a work around (that doesn't include modifying puppet.conf
file) I would be very interested.
Cheers,
Sam
--
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+unsubscr...@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.
Re: [Puppet Users] Re: How do I set global noop?
Sam,
You should setup MCollective. You can implement a simple plugin that
changes the global noop setting in puppet.conf and restarts the
daemon.
That will give you the best scalability, and you have fine-grained
control in MCollective on which hosts run using metadata in your
Puppet classes and facts.
Regards,
Justin
On Sat, Jul 27, 2013 at 10:52 AM, rvlinden
rene.vanderlinde...@gmail.com wrote:
Sam,
You could make some changes to you site.pp and set some defaults like this
Exec {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
File {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Group {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Mount {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Package {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
Service {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
User {
schedule = $::globalvars_schedule,
noop = $::globalvars_noop,
}
. and more .
Make sure that all puppet types you use within you modules are covered in
the site.pp and have the noop = $::globalvars_noop added.
The final step is to set the topscope variable 'globalvars_noop' somewhere
(for example hiera, or Puppet console) and your node will be run with noop.
No need to touch any puppet config on the clients, and very easy to manage
:-)
Regards,
Rene vd Linden
Blog: https://www.rvanderlinden.net/wordpress
On Tuesday, July 23, 2013 1:29:24 AM UTC+2, Sam Morrison wrote:
I'm trying to set a global noop but it doesn't seem possible,
There are 2 bugs open about this which to me look pretty serious as the
expected behaviour isn't the case.
http://projects.puppetlabs.com/issues/21286
http://projects.puppetlabs.com/issues/6549
If anyone has a work around (that doesn't include modifying puppet.conf
file) I would be very interested.
Cheers,
Sam
--
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+unsubscr...@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+unsubscr...@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.
[Puppet Users] Re: Passenger with Puppet 3.0, problems running under
I found that. And I was royally peeved, as nowhere in the logs was there any indication there was an issue. The developers of Passenger pointed out that I can set options in the httpd.conf to specify a user and group -- but these products should be logging better data. I literally spent days, going down avenues that I didn't need to go in order to solve this problem, which I randomly found by continuing to Google around. SMH -- 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+unsubscr...@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.
