The idea is that let say I have a Class define as helperFunctions where I put
in a bunch of shell script exec resources, along with some file resources as
requirement.
Can I then have other classes' resource to Subscribe and/or Notify to specific
Exec resource within that helperFunction
: KENNETH LO k...@paydiant.commailto:k...@paydiant.com
Reply-To: puppet-users@googlegroups.commailto:puppet-users@googlegroups.com
puppet-users@googlegroups.commailto:puppet-users@googlegroups.com
Date: Thu, 16 Aug 2012 15:32:01 +
To: puppet-users@googlegroups.commailto:puppet-users
with the :: prefix.
--KL
From: Rakesh K [mailto:rkath...@gmail.com]
Sent: Wednesday, August 08, 2012 1:52 AM
To: puppet-users@googlegroups.com
Cc: Kenneth Lo
Subject: Re: [Puppet Users] Re: Passing parameters for a class in Dashboard
Ok.. I understand ... I can simply include the class and assign
On a vanilla resource require statement, is there a way to define a require for
either 'resource A' or 'resource B' ?
Historically our system setup increment app per version (as opposed to having a
parameter to define it). Ie. Say, we have a tomcat_6 and tomcat_7 classes for
tomcat v.6 and v.7
In dashboard parameters are assigned via group.
So basically you just create a group, assign some parameters there, include
some nodes and your class in it.
Parameters created via dashboard group are at the global top scope I believe.
--KL
From: Rakesh K
I want to gather some ideas and/or best practice with the fine folks here in
the group in terms of how you manage services in your environment.
For essential services like ssh, it's pretty much standard affair with the
basic Package/Config/Service paradigm. Monitor the package info, make sure
The way I understand it is that, if your puppet installation utilize ENC, you
simply setup the puppet.conf's [master] external_nodes parameter to point to a
process that returns a yaml formatted node catalogs. If your ENC
configuration is correct (in this case dashboard), puppet would do the
We have a similar setup. The way we do this is to simply enforce as a
procedure to create a group and each class we declared, then we would
reference the class in that group, and create variables under that group.
From dashboard's organization standpoint we would only assign nodes to a
group
If that's the case I believe your pe-puppet-dashboard-workers service died
somehow in your master.
--KL
On 2/23/12 9:51 AM, Robert Stinnett rob...@robertstinnett.com wrote:
We are using RHEL - 2.6.18-238.1.1.0.1.el5xen
I do not know of any recent kernel patches (let me put it this way --
I
In PE, pe-activemq is the server service (master need that service) and
pe-mcollective is the client service (agents).
If you don't see your agents listed in LM normally means that the
pe-mcollective service is not running on the clients.
What I've experienced with PE is that under normal
We've been using mcollective primarily for coordinate service restart across
nodes as well as facts-finding, which are all well and good.
One thing we would like to utilize this tool is to create an arbitrary shell
command plugins/services so our master can really act as a command center.
I
Eric:
Can you elborate on why global variables is a bad idea? Most of my
environment's key-value pairs are set via dashboard as ENC, which I think are
all global.
--KL
From: Eric Shamow e...@puppetlabs.commailto:e...@puppetlabs.com
Reply-To:
I'm still relatively new on puppet, but we've been using dashboard quite
extensively so I'm hoping I'm providing the correct answer:
From dashboard a class is simply a place-holder for referencing puppet module
from the backend.
A group is where you can assign classes into nodes, as well as
Hi Nan:
I'm interested to know more regarding your comment. In my environment
we've decided to use dashboard for ENC and the one true source for
customization (parameters, node configuration etc).
Where is the place to check on tutorial and documentation your suggestion?
I have no real prior
The way my environment setup is that we have puppet dashboard handles ALL node
registration as well as class assignment. We simply declare different groups,
assign them with classes, and assign nodes into those groups for different
roles.
So we have zero usage for another node resources and
for general practice for application
deployment?
On Tue, Dec 20, 2011 at 8:26 AM, Kenneth Lo
k...@paydiant.commailto:k...@paydiant.com wrote:
Hi:
I have a pretty general high-level question regarding application deployment
using puppet infrastructure.
Being new with puppet here we have a pretty
Hi:
I have a pretty general high-level question regarding application deployment
using puppet infrastructure.
Being new with puppet here we have a pretty simple module setup where we are
utilizing a basic package-file-service combo for an tomcat application server,
and with some additional
This works. thx!
Another rookie question, what is the :: in front of the variable name
signify in general?
--KL
On Tue, Dec 13, 2011 at 3:37 PM, Stefan Heijmans
heijm...@rechtspraak.nl wrote:
How about something like;
$hasfile = true
if $::hasfile {
$fileensure = 'present'
}
else {
right, the reason I did not opt for this syntax is because my file
resource is actually quite large, and I think the other method Stefan
suggested has better readability.
On Wed, Dec 14, 2011 at 7:34 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
This should also work:
file {
Searching old archive I find this topic:
http://groups.google.com/group/puppet-users/browse_thread/thread/187ee3897a26ae2a/32fea612e79dda80?hl=enlnk=gstq=puppet+case+statement+in+file+resource#32fea612e79dda80
I understand that case statements must be outside of resource
statements per that
20 matches
Mail list logo
