[Puppet Users] Re: Resource ordering of Execs not working as expected (SOLVED)
Hrm, well, with your help, I got this to work in the order I was expecting.
I think I had a few problems here.
1. My original ordering was:
File['Config'] - Exec['stop'] - Package['foo'] - Exec['start']
I changed this to:
File['Config'] ~ Exec['stop'] - Package['foo'] ~ Exec['start']
It helps when I RTFM on using ~ for notifications instead of - for pure
ordering.
2. When I wasn't using that ordering syntax, I had:
exec { stop:
path=
/usr/local/sbin/:/usr/local/jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin,
command = '/usr/local/sbin/control.sh stop',
refreshonly = true,
logoutput = true,
subscribe = File['Config'],
require = File['/usr/local/sbin/control.sh']
}
This is because there are cases when the foo::config is created, but foo is
not (meaning the control files are not created). I figured this would
create the proper order, but it doesn't seem to have.
3. Using different types of configuration patterns. I kept flipping
between using subscribe/notify and -/~ ordering syntax and most likely
screwed something up in the interim. I eventually made a mistake and got
some dependency cycle issues which actually helped quite a bit in figuring
out my error in logic.
BTW, refreshonly = true is still set on both execs and is working
properly.
Thank you for the help!!!
Jake
On Monday, September 22, 2014 7:44:34 AM UTC-7, jcbollinger wrote:
On Friday, September 19, 2014 12:59:34 PM UTC-5, Jake Lundberg wrote:
Puppet 3.6.2
First, I understand that Execs try not to run multiple times if called
many times by many resources and typically wait until they've all been
collected from all resources
Not exactly. Execs run at most twice per Puppet run. They run at most
once if they are refreshonly or if they do not receive any events from
other resources. (If they are refreshonly then they run *only* if they
receive an event from another resource.) When they run relative to when
other resources are applied (and whether resources send them events) is
shaped by resource relationships, just as with all other resource types.
ObYoda: Do... or do not. There is no 'try'.
, but I have a specific case where I need different Execs to run in a
particular order based on a set of resources that change.
That's what resource relationships are for. Cristian has showed you how.
If that doesn't seem to be working for you then it would help us help you
if you present a complete -- but simple -- example that demonstrates your
problem.
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7a4f2132-2f53-47bf-afb1-80e5d25988d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Resource ordering of Execs not working as expected
Puppet 3.6.2
First, I understand that Execs try not to run multiple times if called many
times by many resources and typically wait until they've all been
collected from all resources, but I have a specific case where I need
different Execs to run in a particular order based on a set of resources
that change.
The basic pattern is:
1. Install/update Configuration file (configuration gets updated on all
version changes)
2. Stop Exec script subscribes to Configuration file
3. Package Install/update notifies Start Exec script
4. Package requires Configuration file
The basic resource ordering in the manifest looks like:
require foo::config # This contains the File['Config'] resource
#This might be redundant, but trying to force this relationship
File['Config'] - Package[foo]
package { [foo]:
ensure = ${version}-${release},
notify = Exec['start']
}
# Start, stop, restart functions for ads server
file {/usr/local/sbin/control.sh:
source = puppet:///modules/foo/control.sh,
ensure = present,
owner = root,
group = root,
mode = 0744,
}
exec { stop:
path=
/usr/local/sbin/:/usr/local/jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin,
command = '/usr/local/sbin/control.sh stop',
refreshonly = true,
logoutput = true,
subscribe = File['Config'],
require = File['/usr/local/sbin/control.sh']
}
exec { start:
path=
/usr/local/sbin/:/usr/local/jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin,
command = '/usr/local/sbin/control.sh start',
refreshonly = true,
logoutput = true,
require = File['/usr/local/sbin/control.sh']
}
However, when puppet apply runs this is what happens:
1. Configuration file is installed/updated, schedules a refresh of Stop
Exec
2. Package is installed, schedules refresh of Start Exec
3. Start Exec runs
4. Stop Exec runs
There's probably a better way of doing this (possibly with run stages), I'm
just curious why this plan does not work. I'm very open to improvements.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b892a4d6-4356-40ab-95a2-ab8ca218e2d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Resource ordering of Execs not working as expected
Yes Cristian, I understand that, but the issue is less the order of the
Execs in relation to each other, but when the Execs run in relation to the
config file resource and the package resource. I need for the stop Exec
to run before the package is installed, and then the start Exec to run.
This may be an issue with using Execs in the first place due to the way the
get collected and their execution strategy to reduce duplicate runs.
I'm hoping execution order is: File['Config'] - Exec['stop'] -
Package['foo'] - Exec['start']
(In fact I used that exact ordering syntax at one point).
BTW, using:
Exec['stop'] - Exec['start'] did cause stop to run before start, just
AFTER Package['foo'] is installed, so thank you for that. This doesn't
solve my issue however as I really need the stop to run before package
installation/upgrade.
Jake
On Friday, September 19, 2014 11:13:11 AM UTC-7, Cristian Falcas wrote:
The order of resources in the manifest doesn't matter. Puppet will build a
graph from all resources and dependencies and executes resources from the
same level randomly.
You need something like this:
exec { start:
path=
/usr/local/sbin/:/usr/local/jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin,
command = '/usr/local/sbin/control.sh start',
refreshonly = true,
logoutput = true,
require = [File['/usr/local/sbin/control.sh'], Exec['stop'],
}
On Fri, Sep 19, 2014 at 8:59 PM, Jake Lundberg jlun...@adconion.com
javascript: wrote:
Puppet 3.6.2
First, I understand that Execs try not to run multiple times if called
many times by many resources and typically wait until they've all been
collected from all resources, but I have a specific case where I need
different Execs to run in a particular order based on a set of resources
that change.
The basic pattern is:
1. Install/update Configuration file (configuration gets updated on all
version changes)
2. Stop Exec script subscribes to Configuration file
3. Package Install/update notifies Start Exec script
4. Package requires Configuration file
The basic resource ordering in the manifest looks like:
require foo::config # This contains the File['Config'] resource
#This might be redundant, but trying to force this relationship
File['Config'] - Package[foo]
package { [foo]:
ensure = ${version}-${release},
notify = Exec['start']
}
# Start, stop, restart functions for ads server
file {/usr/local/sbin/control.sh:
source = puppet:///modules/foo/control.sh,
ensure = present,
owner = root,
group = root,
mode = 0744,
}
exec { stop:
path=
/usr/local/sbin/:/usr/local/jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin,
command = '/usr/local/sbin/control.sh stop',
refreshonly = true,
logoutput = true,
subscribe = File['Config'],
require = File['/usr/local/sbin/control.sh']
}
exec { start:
path=
/usr/local/sbin/:/usr/local/jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin,
command = '/usr/local/sbin/control.sh start',
refreshonly = true,
logoutput = true,
require = File['/usr/local/sbin/control.sh']
}
However, when puppet apply runs this is what happens:
1. Configuration file is installed/updated, schedules a refresh of Stop
Exec
2. Package is installed, schedules refresh of Start Exec
3. Start Exec runs
4. Stop Exec runs
There's probably a better way of doing this (possibly with run stages),
I'm just curious why this plan does not work. I'm very open to
improvements.
--
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...@googlegroups.com javascript:.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b892a4d6-4356-40ab-95a2-ab8ca218e2d1%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/b892a4d6-4356-40ab-95a2-ab8ca218e2d1%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5650e7cd-267c-45ac-9ae0-df0c144c508c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Change Hostname on Puppet Master
Do you even need to do this? Can't you just use the certname configuration variable on the puppetmaster and just set it to the old name? On Wednesday, August 6, 2014 3:40:38 AM UTC+7, Jose Luis Ledesma wrote: +1 You don't need to re-register all clients. Just generate a new cert for the master with both old and new name and sign in. Regards El 05/08/2014 19:29, Nan Liu nan...@gmail.com javascript: escribió: On Tue, Aug 5, 2014 at 10:11 AM, Gabriel Filion gab...@lelutin.ca javascript: wrote: Hey there, On 05/08/14 10:45 AM, Danny Roberts wrote: We have a requirement to change the Host name of our Puppet Master (not a great idea but sadly out of my control). I could not find any documentation on this subject, does nayone know the process for doing something like this? Or would it need to be a complete rebuild then re-import of our Puppet code? I did this some time ago and ended using the stupid method. So if there's a better way than what I'll describe, please someone step in. What really matters when you rename your master is your master SSL certificate. Clients will be verifying if the puppet master's hostname matches the one advertised by the certificate. So when I changed the hostname, I had to create a new certificate for the master, and then recreate certificates for clients and re-registering all clients to the master. e.g.: on all clients: * wipe out /var/lib/puppet/ssl * run puppet agent -t --waitforcert 10 * on master, sign client certificate this was very time-consuming though. Please don't resign all client certificates. All you need to do is recreate a puppet master certificate with dns alt name accepting both the old and new puppet master hostname. Because passenger and other configuration may already refer to the existing pem file name, it's easier to just add the new hostname to the dns_alt_names accept list: Backup your puppet master ssl directory, so you can just retry if something didn't go as planned. # note all certificate alt names of the existing puppet master cert: puppet cert -la | grep oldmaster (alt names DNS:puppet, DNS:puppet-master, DNS:puppet.mgmt, ) ... # remove your old puppet master cert. puppet cert -c oldmaster # search the ssl dir and it should not have any files with the oldmaster certname # generate new master cert (same name as old one, but accept new_hostname in dns_alt_names): puppet cert -g oldmaster --dns_alt_names=new_hostname,puppet,puppet-master,puppet.mgmt # you may need to copy the files to some locations if you found files not removed after the cert clean step At this point you can add a host entry on one of your agents and test via: puppet agent -t --server new_hostname --noop You should not have to touch any client cert, that's only necessary if you need to change your CA cert which is a pain when it expires. HTH, Nan -- 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...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACqVBqCAUEdWujqa6UW%2BfzgJ1y3Db5bjGSOE8Qh5UU_ErqUhCw%40mail.gmail.com https://groups.google.com/d/msgid/puppet-users/CACqVBqCAUEdWujqa6UW%2BfzgJ1y3Db5bjGSOE8Qh5UU_ErqUhCw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e3813e2f-832e-4c61-bd97-367dc71f1d45%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Change Hostname on Puppet Master
Actually, disregard, I'm thinking of the client side. -- Jake Lundberg Senior Systems Engineer jlundb...@adconion.com +1.310.382.5581 On Wed, Aug 6, 2014 at 11:12 PM, Jake Lundberg jlundb...@adconion.com wrote: Do you even need to do this? Can't you just use the certname configuration variable on the puppetmaster and just set it to the old name? On Wednesday, August 6, 2014 3:40:38 AM UTC+7, Jose Luis Ledesma wrote: +1 You don't need to re-register all clients. Just generate a new cert for the master with both old and new name and sign in. Regards El 05/08/2014 19:29, Nan Liu nan...@gmail.com escribió: On Tue, Aug 5, 2014 at 10:11 AM, Gabriel Filion gab...@lelutin.ca wrote: Hey there, On 05/08/14 10:45 AM, Danny Roberts wrote: We have a requirement to change the Host name of our Puppet Master (not a great idea but sadly out of my control). I could not find any documentation on this subject, does nayone know the process for doing something like this? Or would it need to be a complete rebuild then re-import of our Puppet code? I did this some time ago and ended using the stupid method. So if there's a better way than what I'll describe, please someone step in. What really matters when you rename your master is your master SSL certificate. Clients will be verifying if the puppet master's hostname matches the one advertised by the certificate. So when I changed the hostname, I had to create a new certificate for the master, and then recreate certificates for clients and re-registering all clients to the master. e.g.: on all clients: * wipe out /var/lib/puppet/ssl * run puppet agent -t --waitforcert 10 * on master, sign client certificate this was very time-consuming though. Please don't resign all client certificates. All you need to do is recreate a puppet master certificate with dns alt name accepting both the old and new puppet master hostname. Because passenger and other configuration may already refer to the existing pem file name, it's easier to just add the new hostname to the dns_alt_names accept list: Backup your puppet master ssl directory, so you can just retry if something didn't go as planned. # note all certificate alt names of the existing puppet master cert: puppet cert -la | grep oldmaster (alt names DNS:puppet, DNS:puppet-master, DNS:puppet.mgmt, ) ... # remove your old puppet master cert. puppet cert -c oldmaster # search the ssl dir and it should not have any files with the oldmaster certname # generate new master cert (same name as old one, but accept new_hostname in dns_alt_names): puppet cert -g oldmaster --dns_alt_names=new_hostname, puppet,puppet-master,puppet.mgmt # you may need to copy the files to some locations if you found files not removed after the cert clean step At this point you can add a host entry on one of your agents and test via: puppet agent -t --server new_hostname --noop You should not have to touch any client cert, that's only necessary if you need to change your CA cert which is a pain when it expires. HTH, Nan -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/puppet-users/CACqVBqCAUEdWujqa6UW%2BfzgJ1y3Db5bjGSOE8Qh5UU_ ErqUhCw%40mail.gmail.com https://groups.google.com/d/msgid/puppet-users/CACqVBqCAUEdWujqa6UW%2BfzgJ1y3Db5bjGSOE8Qh5UU_ErqUhCw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/jLeuapo7n1c/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e3813e2f-832e-4c61-bd97-367dc71f1d45%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/e3813e2f-832e-4c61-bd97-367dc71f1d45%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAFFwF1c%3DDPT9sz3h87sLzrW8n-N_2YCQ2vj_JhHP-Bxz7ddYCg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Hiera/Puppet: How to handle different versions of applications in multiple environments?
When it comes to split responsibilities, such as that between the Ops teams
and Dev teams, we usually do a couple things:
1. Use hiera to store key/value pairs that can be visible worldwide (like
application versions). This allows developers to be able to test their own
stuff, and when ready, submit pull requests into the production environment
branches
2. Use node scoped variables for Ops-only information
3. Make Ops the keeper of facts and secrets in the node definitions
4. Structure our hierarchy to include applications, datacenters and/or
business units (ours is actually more complex, but this is simplified)
5. Parameterize all classes we wish to use hiera for.
5.1 In some cases, explicitly call hiera based on availability of node
scoped variables (this is more for pre-hiera backwards compatibility)
6. Use folder based environments (though it seems Puppet suggests moving
away from these, they give us more flexibility). We use a script we found
on the github called branch2env.py (slightly modified to fit our
environment better). I haven't used r10k, but it sounds like it does
something similar.
The actual node definition might look something like:
node vars-dc1-finance {
# This is the folder for puppet/hiera code to look at
$environment = 'production'
# These are facts that aid in hiera lookups
$datacenter = 'dc1'
$biz = 'finance'
# This is a node scoped secret
$order_service::webapp::password = 'foofoo'
}
node finance-webapp.dc1.com inherits vars-dc1-finance {
include base
include order_service::webapp
}
A basic hierarchy might be:
- nodes/%{::fqdn}
- dc/%{datacenter}
- biz/%{biz}
- common
Some example hiera yamls:
dc/dc1.yaml:
order_service::webapp::endpoint1: 'https://endpoint1.dc1.com'
base::yum_repo_server: 'repo.dc1.com'
biz/finance.yaml:
java::version: '1.7.0_60'
order_service::webapp::version: '1.2.3'
biz/hr.yaml:
java::version: '1.6.0_30'
order_service::webapp::version: '1.0.0'
common.yaml:
#This pulls from a node scoped variable
order_service::webapp::password: %{order_service::webapp::password}
# These are defaults in the event something higher in the hierarchy does
define them.
java::version: '1.6.0_18'
order_service::webapp::version: '1.0.0'
Now for some basic class definitions:
class order_service::webapp ($version, $password, $endpoint1) {
include java
package { order_service-${version} :
ensure = installed
}
file { /etc/creds/order_service :
content = ${password}
}
# This template uses the $endpoint1 variable via %= @endpoint1 %
file { /etc/overrides/order_service:
content = template(order_service/webapp/overrides.xml.erb)
}
}
class java ($version) {
package { jdk-${version} :
ensure = installed
}
}
Our hiera and modules are environment aware. And environment is stored in
puppet.conf via an erb.
hiera.yaml:
:datadir: /etc/puppet/hiera/%{environment}
puppet.conf:
environment = production (This is added via an erb template that reads the
node scoped $environment variable)
modulepath = /etc/puppet/modules/$environment
Our nodes are included in site.pp from a predefined location. This allows
us to do a couple things:
1. Keep tighter control of production assets
2. Allow developers to add in node definitions in cases this is necessary
(mainly due to old policies).
e.g.
import /etc/puppet/nodes/prod/* (points to a for-Ops-only repo)
import /etc/puppet/nodes/dev/* (points to a developer accessed repo)
We went through a few iterations of getting this right and figuring out how
to reduce duplication of data as much as possible. Just try to remember a
few things:
1. Try to keep your node definitions as simple as possible. When possible
only add facts not derived from facter to node definitions.
2. Keep configuration data out of your classes. Even defaults. Use
common.yaml or similar to add in defaults.
3. Unless absolutely necessary DO NOT use resource style declarations
(e.g. class { java: version = '1.7.0_60'}). Hiera handles parameter
lookups quite well and you won't get duplicate declaration issues.
HTH,
Jake
On Saturday, August 2, 2014 2:44:05 AM UTC+7, Devminded wrote:
Hi Pete.
I ended up doing just that, class variables for versions of applications
backed by Hiera. I am trying to avoid putting %{environment} in Hiera to
keep different jurisdictions from interfering with each other. I just use
directory environments for both Hiera data and puppet modules.
Now I did end up with the issue I was afraid of: A messy mix of
infrastructure data owned by Ops (IP-addresses, nodes, clustering,
firewall, etc) with all the application data that is owned by delivery
(what things are tested and integrated together).
I'm thinking that my hierarchy is wrong and will try to separate the
application versions from infrastructure data and retrieve them from
separate repos. I'm fairly new to Hiera so I don't know if that will even
work... will
[Puppet Users] Hiera + GPG: If GPG first backend, yaml (non-gpg) entries cause failure
I'm able to get Hiera + GPG working fine, but am running into an issue when
I want to use GPG as the primary backend. We want to do this to make sure
any secrets are realized first. However, it seems when a value in GPG
backend also exists in a YAML backend, hiera dies with a message:
Debug: Automatically imported puppet::client from puppet/client into
DEVENV_20131205_2000
Debug: hiera(): [gpg_backend]: Loaded gpg_backend
Debug: hiera(): [gpg_backend]: Lookup called, key
puppet::client::runinterval resolution type is
Debug: hiera(): [gpg_backend]: GNUPGHOME is /etc/puppet/gpgkeys
Debug: hiera(): [gpg_backend]: loaded cipher:
/etc/puppet/hiera/DEVENV_20131205_2000/adhoc.gpg
Debug: hiera(): [gpg_backend]: result is a String ctx
#GPGME::Ctx:0x2b191de61458 txt ---
encryption_key: 'HIERA + GPG ROCKS!'
integrity_key: 'HIERA + GPG ROCKS!'
SNIP
Debug: hiera(): Looking for data source env/ec2-labs/lab3
Error: undefined method `read_file' for #Hiera::Filecache:0x2b191dd93760
@cache={} at
/etc/puppet/modules/DEVENV_20131205_2000/base_server/manifests/init.pp:12
on node node
Wrapped exception:
undefined method `read_file' for #Hiera::Filecache:0x2b191dd93760
@cache={}
Error: undefined method `read_file' for #Hiera::Filecache:0x2b191dd93760
@cache={} at
/etc/puppet/modules/DEVENV_20131205_2000/base_server/manifests/init.pp:12
on node node
Error: undefined method `read_file' for #Hiera::Filecache:0x2b191dd93760
@cache={} at
/etc/puppet/modules/DEVENV_20131205_2000/base_server/manifests/init.pp:12
on node node
adhoc.gpg is higher in the hierarchy, env/ec2-labs/lab3 is lower, but holds
values for the node the catalog is being built for. In this particular
case, the encryption_key and integrity_key values have been commented
out of lab3.yaml.
If I switch to have YAML as the primary provider, everything works, but I
get the YAML value as opposed to the GPG value (if both are defined).
If the value doesn't exist in the YAML, everything works perfectly if GPG
is the secondary backend, however, since our repository is shared between
teams, we want to make GPG the primary value.
Is there some sort of cache collision if GPG values are created for a
node's variables in the catalog first?
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2736927d-5f7a-4026-99ff-da6f510ade4f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppet apply manifest command line parameters
I suppose it depends on how you structure your manifest. We typically
apply a manifest to a particular node when testing new manifests. So
something like:
site.pp:
node default {
$param1 = value1
$param2 = value2
include exec_class
}
/etc/puppet/modules/exec_class/manifests/init.pp
class exec_class ( $param1, $param2) {
exec { do something :
command = /usr/local/bin/exec_something.sh
}
}
# puppet apply --modulepath=/etc/puppet/modules site.pp
I also think you can pass parameters via
facter:
http://stackoverflow.com/questions/15901850/pass-variable-to-puppet-on-commandline
On Sunday, December 8, 2013 7:31:27 PM UTC-8, Sachin Nikam wrote:
I am newbie to puppet(versin 2.7) and came up with a manifest that
contains some exec tasks. when I invoke the puppet apply manifest, I
want to pass in some parameters specific to my application. How do I do
that? I searched the online documentation but couldn't find any examples.
Regards
Sachin
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/36932f82-1f68-42a9-b081-9b8fbd0ffb59%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppet apply manifest command line parameters
Oops, that should probably read:
exec { do something :
command = /usr/local/bin/exec_something.sh ${param1} ${param2}
}
On Monday, December 9, 2013 11:46:17 AM UTC-8, Jake Lundberg wrote:
I suppose it depends on how you structure your manifest. We typically
apply a manifest to a particular node when testing new manifests. So
something like:
site.pp:
node default {
$param1 = value1
$param2 = value2
include exec_class
}
/etc/puppet/modules/exec_class/manifests/init.pp
class exec_class ( $param1, $param2) {
exec { do something :
command = /usr/local/bin/exec_something.sh
}
}
# puppet apply --modulepath=/etc/puppet/modules site.pp
I also think you can pass parameters via facter:
http://stackoverflow.com/questions/15901850/pass-variable-to-puppet-on-commandline
On Sunday, December 8, 2013 7:31:27 PM UTC-8, Sachin Nikam wrote:
I am newbie to puppet(versin 2.7) and came up with a manifest that
contains some exec tasks. when I invoke the puppet apply manifest, I
want to pass in some parameters specific to my application. How do I do
that? I searched the online documentation but couldn't find any examples.
Regards
Sachin
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/81157a24-fa6e-46fa-ac71-4a4474a5ab55%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppet apply manifest command line parameters
No, not like that.
You could create your own custom fact and use that via command line.
See:
http://www.practicalclouds.com/content/guide/converting-user-data-arguments-facts.
It's not a perfect example, but does have some logic for parsing
arguments.
As you're a self proclaimed newbie, this may take longer than you wish.
Another option is you can wrap creating your manifest (site.pp or imports)
in a script, but that's probably not the ideal solution.
What are you trying to do? Arbitrary remote execution of commands? If
so, Puppet might not be the best platform. Consider something like
Fabric/Capistrano, Ansible or Salt Stack (or just plain Bash).
On Monday, December 9, 2013 12:50:44 PM UTC-8, Sachin Nikam wrote:
Jake,
I want to do something like this...
# puppet apply --modulepath=/etc/puppet/modules site.pp somevalue1
somevalue2
is this possible?
Regards
Sachin
On Monday, 9 December 2013 11:48:16 UTC-8, Jake Lundberg wrote:
Oops, that should probably read:
exec { do something :
command = /usr/local/bin/exec_something.sh ${param1} ${param2}
}
On Monday, December 9, 2013 11:46:17 AM UTC-8, Jake Lundberg wrote:
I suppose it depends on how you structure your manifest. We typically
apply a manifest to a particular node when testing new manifests. So
something like:
site.pp:
node default {
$param1 = value1
$param2 = value2
include exec_class
}
/etc/puppet/modules/exec_class/manifests/init.pp
class exec_class ( $param1, $param2) {
exec { do something :
command = /usr/local/bin/exec_something.sh
}
}
# puppet apply --modulepath=/etc/puppet/modules site.pp
I also think you can pass parameters via facter:
http://stackoverflow.com/questions/15901850/pass-variable-to-puppet-on-commandline
On Sunday, December 8, 2013 7:31:27 PM UTC-8, Sachin Nikam wrote:
I am newbie to puppet(versin 2.7) and came up with a manifest that
contains some exec tasks. when I invoke the puppet apply manifest, I
want to pass in some parameters specific to my application. How do I do
that? I searched the online documentation but couldn't find any examples.
Regards
Sachin
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/422ae7c4-3dd0-4035-b93f-6935fce4e1ee%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
