This seems to be incorrect in the documentation:
http://docs.reductivelabs.com/guides/types/host.html
Might cause confusion!
On Mar 26, 1:04 pm, Dan Bode wrote:
> On Fri, Mar 26, 2010 at 5:02 AM, DieterVDW wrote:
> > Hi,
>
> > I've got the following resource:
>
&
Hi,
I've got the following resource:
host { "host.domain.com":
alias => [ "host", "alias" ],
ip => "1.2.3.4",
ensure => present,
}
The resulting line in my /etc/hosts file is:
1.2.3.4 host.domain.com
Any alias definitions seem to be ignored?
What am I doing wrong?
Best regards,
Di
I'm also having this issue.
Seems random. On the following run things seem to go ok.
Seems like a bug to me?
On Mar 15, 5:29 pm, Kent Rankin wrote:
> We keep getting a variety of these from a random set during each Puppet run:
>
> Sat Mar 13 23:46:42 -0500 2010 //cups/File[/etc/cups] (err): Faile
Hi,
I'd like to hear some idea's on how to do the following with puppet:
Suppose I have a node that implements a certain server class, eg. nfs-
server,
and some other nodes that implement a class nfs-client.
I'd like all nodes that implement nfs-client to contain a reference to
the node that impl
on the puppet client, but doesn't
seem to do anything?
I guess it's the server sending the previous working config?
What's the best way to detect and signal there is an error in the
manifests?
It would be nice to know if you've made a mistake and the changes
you're expectin
Hi,
I was wondering what is the correct way to make sure changes in the
manifest files are applied to the relevant nodes.
When using puppet -tv everything works as expected, but when running
puppetd as a daemon, caching is playing games with me. Apparently
changes are not applied until the cache
On Mar 12, 2:48 pm, Brice Figureau
wrote:
> Yes it is, because it happens in the "file serving" code as part of
> getting information about a given file. This part of the process doesn't
> know getting the checksum is unnecessary (in fact this is the same code
> that is used to serve file metadata
On Mar 12, 2:21 pm, Brice Figureau
wrote:
> It is checksumming every file.
Aha. This is a known issue?
Is there a bugreport for this?
Possibly a patch?
Is it normal no debug information is shown during this process?
--
You received this message because you are subscribed to the Google Groups
d using --debug, but no debug statements are printed
either during the entire time puppetd is hogging the CPU.
Will have a second look though, maybe something interesting is printed
earlier...
On Mar 12, 1:58 pm, Martin Wheldon wrote:
> Hi,
>
> Is this directory the only resource you are man
nutes .
So by manipulating the execution of puppetd using a CTRL-C keystroke I
can reach the intended end state in 4 minutes.
If I leave puppetd to do it by itself, it takes 30+ minutes of 100%
CPU usage...
On Mar 12, 1:43 pm, DieterVDW wrote:
> Aren't the time values in seconds?
> Becau
#x27;s file structure.
>
> That said, for deep directory/many file file statements, just spawn an
> exec until the internal Puppet logic can be optimized.
>
> Trevor
>
>
>
> On Fri, Mar 12, 2010 at 6:32 AM, DieterVDW wrote:
> > Some more information from the (undocumen
: 1.42
User: 0.01
Total: 54.78
warning: Value of 'preferred_serialization_format' (pson) is invalid
for report, using default (marshal)
notice: Finished catalog run in 1877.06 seconds
It seems to me the cause of the delays is not recorded in the time
overview?
D
On Mar 12, 12:30 pm, Dieter
On Mar 12, 11:21 am, Patrick wrote:
> Puppet doesn't handle a folder with lots of files well. It handles large
> files even worse. The standard advice is "Try putting the files in a package
> and distributing them using apt." Another common answer is to try combining
> exec and rsync. I end
Hi,
I've been experimenting with Puppet for a few days now, and I really
like it.
But! I'm having real CPU usage problems.
Puppet is still happily eating away 100% CPU for almost an hour at a
time, with no apparent things happening.
(puppetd -tv --trace --debug, but nothing appearing in the conso
14 matches
Mail list logo
