I can confirm this. Same issue here.
On Thursday, December 26, 2013 1:54:33 PM UTC-5, Fabrice Bacchella wrote:
>
> When I upgrade a node with puppet 3.4.0, puppet-package is broken :
>
> ~$ mco package puppet status -I $(facter hostname) -v
>
> | [ >
I'm having the exact same issue. Anyone had success with puppet 3 ruby19
and Amazon linux? Any help?
On Monday, October 7, 2013 11:27:41 AM UTC-4, Robert Logan wrote:
>
>
> I've been trying to use the ruby19 and rubygems19 packages from amazons
> yum repo but cant get around this issue:
>
> [r
Thanks Josh... I made some comments on that ticket and added a vote.
On Tuesday, December 3, 2013 1:15:49 PM UTC-5, Josh Cooper wrote:
>
>
>
>
> On Tue, Dec 3, 2013 at 10:01 AM, Glenn Poston
> > wrote:
>
>> I was curious how much of an effect the long running exter
tion when it
worked perfectly fine?
On Tuesday, December 3, 2013 12:33:35 PM UTC-5, R.I. Pienaar wrote:
>
>
>
> - Original Message -
> > From: "Glenn Poston" >
> > To: puppet...@googlegroups.com
> > Sent: Tuesday, December 3, 2013 5:30:30 PM
>
This bug has been reported, but I think it's severity is understated.
Please vote for these bugs.
https://projects.puppetlabs.com/issues/22944 -> original
https://projects.puppetlabs.com/issues/23335 -> mine (duplicate)
--
You received this message because you are subscribed to the Google Grou
I was curious how much of an effect the long running external fact was
effecting the timing, so I updated the external fact script to simply echo
the content (instead of fetching it from s3). The facts it produced were
the same as if it had fetched the facts from S3.
I then introduced a 'sleep
On Tuesday, December 3, 2013 11:08:33 AM UTC-5, jcbollinger wrote:
>
>
>
> On Wednesday, November 27, 2013 11:17:44 PM UTC-6, Glenn Poston wrote:
>>
>> My external fact script takes 5s to run.
>>
>> With external fact...
>> puppet takes 2.5m to ru
Any ideas anyone?
[vagrant@fisheye-10-0-2-15 ~]$ facter --version
1.7.3
[vagrant@fisheye-10-0-2-15 ~]$ puppet --version
3.3.2
On Thursday, November 28, 2013 12:17:44 AM UTC-5, Glenn Poston wrote:
>
> My external fact script takes 5s to run.
>
> With external fact...
> puppet ta
My external fact script takes 5s to run.
With external fact...
puppet takes 2.5m to run
facter takes 33s to run
Without external fact...
puppet takes 27s to run
facter takes 0.68s
Bottom line... there's no significant change in facter runtime when parsing
the external fact, but the puppet runti
>From http://docs.puppetlabs.com/guides/custom_facts.html
If you are interested in finding out where any bottlenecks are, you can run
> Facter in timing mode and it will reflect how long it takes to parse your
> external facts:facter --timingThe output should look similar to the
> timing for R
uesday, September 3, 2013 1:41:22 PM UTC-5, Glenn Poston wrote:
> Any ideas???
>
> On Friday, June 28, 2013 9:38:29 AM UTC-4, Glenn Poston wrote:
> Running Amazon Linux (which is essentially Centos5.5).
>
> Anyone seen random yum errors like this one? I don't think it's
Any ideas???
On Friday, June 28, 2013 9:38:29 AM UTC-4, Glenn Poston wrote:
>
> Running Amazon Linux (which is essentially Centos5.5).
>
> Anyone seen random yum errors like this one? I don't think
> it's necessarily related to Puppet, but it randomly fails my puppet
Running Amazon Linux (which is essentially Centos5.5).
Anyone seen random yum errors like this one? I don't think
it's necessarily related to Puppet, but it randomly fails my puppet runs
and I don't know how to fix it.
Jun 28 08:41:34 ip-10-159-65-145 run_puppet: [Notice:
/Stage[main]/Zookeep
We use facter-dot-d as well, but we also take advantage of 'calling_module'
for grouping. This param is automatically available to heira.
Here is our heira.yaml (role is in facter.d)
:hierarchy: - %{environment}/%{fqdn}
- %{environment}/%{role}
- %{environment}/%{calling
I would suggest looking into using Vagrant for local testing before pushing
code. Vagrant up.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/zVMH02fI2
Use heira. Heira can load a config file based on the environment. Setting
this up is as simple as creating a hiera definition such as...
(environment).yaml
... And then creating the following files: production.yaml and staging.yaml
that contain your environment specific configs.
Install the
We have one script that is called to bootstrap and provision new VMs. There's
another one for destroying. These scripts are also responsible for logging
into the puppet master (via ssh), polling for the cert to be created (puppet
cert list) and then issuing the sign/clean commands.
--
You re
Similar setup here: pxe boot, etc. but we keep a pxe booted sparse base image
available to clone. And use a script to to do the clone so that we can
provision more quickly (saves us the pxe boot time). The script also interacts
with puppet dashboard to set the machine role. We can provision
You could create a fact that returns true or false, then use that fact in your
puppet code to determine whether to start the service. I'd need more details
to really say that's the best solution though. Other options would be to use
heira or to use a parameterized class and set those parameter
I'm using hiera to define a list of database engine id's for a node. I'm
using this variable to feed into a defined type to create a set of files
(upstart configs). The problem I would like to solve isŠ.
How do I delete files/resources that were previously created but are now
removed (without de
I second this. I would prefer this config_version to update at compile
time with each client request.
On Monday, January 31, 2011 6:58:29 PM UTC-5, John Warburton wrote:
>
> I have tried to use config_version and failed due to limitations in the
> way I would like to use it:
> - http://projects
21 matches
Mail list logo
