[Puppet Users] Mcollective puppet-agent doesn't execute commands from custom facts
Hello
I met following issue with mcollective puppet agent.
I have custom fact that read tags from AWS cli and transform them to facts.
Facter.add(role) do
setcode do
iregion = Facter.value(ec2_region)
Facter::Util::Resolution.exec(ec2-describe-tags --region #{iregion} -O
KEY -W SEC_KEY --filter \resource-id=$(ec2-metadata -i | cut -d \ \
-f2)\ --filter \key=Role\ | cut -f5 -)
end
end
When I run facter from instance aor puppet agent from instance itself -
everything working fine.
When I run pupper runnonce from mcollective server - it doesn't read this
fact and apply only common manifest.
I checked several times and found, that if I set static file with role and
use external fact like:
#!/bin/bash
role=`grep Role /etc/server_facts | awk '{print $NF}'`
echo role=$role
Mcollective works fine. If Itry to use AWS cli command in script - again
fact doesn't wrk.
Have someone met such problem with mcollective? Can someone advise?
Puppet 3.6.2
Mcollective 2.5.3
--
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/85a8940b-0a4f-4de4-a568-050af439cb00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Mcollective puppet-agent doesn't execute commands from custom facts
Hi
Probably mco is not loading you environment variables ( like PATH) and this
produces this behavior.
If the ec2-describe-tags commands is not in the usual path, try exec it
with the full path in the fact.
Also you can check if the ec2_region fact is get correctly from mco.
Hth
El 02/08/2014 20:57, Maxim Nikolaev m...@maximnik.com escribió:
Hello
I met following issue with mcollective puppet agent.
I have custom fact that read tags from AWS cli and transform them to facts.
Facter.add(role) do
setcode do
iregion = Facter.value(ec2_region)
Facter::Util::Resolution.exec(ec2-describe-tags --region #{iregion} -O
KEY -W SEC_KEY --filter \resource-id=$(ec2-metadata -i | cut -d \ \
-f2)\ --filter \key=Role\ | cut -f5 -)
end
end
When I run facter from instance aor puppet agent from instance itself -
everything working fine.
When I run pupper runnonce from mcollective server - it doesn't read this
fact and apply only common manifest.
I checked several times and found, that if I set static file with role and
use external fact like:
#!/bin/bash
role=`grep Role /etc/server_facts | awk '{print $NF}'`
echo role=$role
Mcollective works fine. If Itry to use AWS cli command in script - again
fact doesn't wrk.
Have someone met such problem with mcollective? Can someone advise?
Puppet 3.6.2
Mcollective 2.5.3
--
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/85a8940b-0a4f-4de4-a568-050af439cb00%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/85a8940b-0a4f-4de4-a568-050af439cb00%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/CAF_B3ddAA%3DeyqXSjvh1S7ptXOVXpJXcor6FgNP%3DCwde8RS1Yxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Mcollective puppet-agent doesn't execute commands from custom facts
Tried also full path with ec2-region hardcoded
/opt/aws/bin/ec2-describe-tags --region us-east-1 -O KEY -W SEC_KEY
--filter \resource-id=$(ec2-metadata -i | cut -d \ \ -f2)\ --filter
\key=Role\ | cut -f5 -)
Created also sh script in /etc/facter/facts.d with same string: when run
locally - it's works, when run with mcollective - it's failed.
I also checked with mcollective-facter-facts plugin - it can see these
facts.
On Saturday, August 2, 2014 10:48:52 PM UTC+3, Jose Luis Ledesma wrote:
Hi
Probably mco is not loading you environment variables ( like PATH) and
this produces this behavior.
If the ec2-describe-tags commands is not in the usual path, try exec it
with the full path in the fact.
Also you can check if the ec2_region fact is get correctly from mco.
Hth
El 02/08/2014 20:57, Maxim Nikolaev m...@maximnik.com javascript:
escribió:
Hello
I met following issue with mcollective puppet agent.
I have custom fact that read tags from AWS cli and transform them to
facts.
Facter.add(role) do
setcode do
iregion = Facter.value(ec2_region)
Facter::Util::Resolution.exec(ec2-describe-tags --region #{iregion} -O
KEY -W SEC_KEY --filter \resource-id=$(ec2-metadata -i | cut -d \ \
-f2)\ --filter \key=Role\ | cut -f5 -)
end
end
When I run facter from instance aor puppet agent from instance itself -
everything working fine.
When I run pupper runnonce from mcollective server - it doesn't read this
fact and apply only common manifest.
I checked several times and found, that if I set static file with role
and use external fact like:
#!/bin/bash
role=`grep Role /etc/server_facts | awk '{print $NF}'`
echo role=$role
Mcollective works fine. If Itry to use AWS cli command in script - again
fact doesn't wrk.
Have someone met such problem with mcollective? Can someone advise?
Puppet 3.6.2
Mcollective 2.5.3
--
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/85a8940b-0a4f-4de4-a568-050af439cb00%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/85a8940b-0a4f-4de4-a568-050af439cb00%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/73fe7b9d-8161-45e6-aa1a-1ec381ef9093%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Mcollective puppet-agent doesn't execute commands from custom facts
And setting full path for ec2-metadata too?
El 02/08/2014 22:02, Maxim Nikolaev m...@maximnik.com escribió:
Tried also full path with ec2-region hardcoded
/opt/aws/bin/ec2-describe-tags --region us-east-1 -O KEY -W SEC_KEY
--filter \resource-id=$(ec2-metadata -i | cut -d \ \ -f2)\ --filter
\key=Role\ | cut -f5 -)
Created also sh script in /etc/facter/facts.d with same string: when run
locally - it's works, when run with mcollective - it's failed.
I also checked with mcollective-facter-facts plugin - it can see these
facts.
On Saturday, August 2, 2014 10:48:52 PM UTC+3, Jose Luis Ledesma wrote:
Hi
Probably mco is not loading you environment variables ( like PATH) and
this produces this behavior.
If the ec2-describe-tags commands is not in the usual path, try exec it
with the full path in the fact.
Also you can check if the ec2_region fact is get correctly from mco.
Hth
El 02/08/2014 20:57, Maxim Nikolaev m...@maximnik.com escribió:
Hello
I met following issue with mcollective puppet agent.
I have custom fact that read tags from AWS cli and transform them to
facts.
Facter.add(role) do
setcode do
iregion = Facter.value(ec2_region)
Facter::Util::Resolution.exec(ec2-describe-tags --region #{iregion}
-O KEY -W SEC_KEY --filter \resource-id=$(ec2-metadata -i | cut -d \ \
-f2)\ --filter \key=Role\ | cut -f5 -)
end
end
When I run facter from instance aor puppet agent from instance itself -
everything working fine.
When I run pupper runnonce from mcollective server - it doesn't read this
fact and apply only common manifest.
I checked several times and found, that if I set static file with role
and use external fact like:
#!/bin/bash
role=`grep Role /etc/server_facts | awk '{print $NF}'`
echo role=$role
Mcollective works fine. If Itry to use AWS cli command in script - again
fact doesn't wrk.
Have someone met such problem with mcollective? Can someone advise?
Puppet 3.6.2
Mcollective 2.5.3
--
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/85a8940b-0a4f-4de4-a568-050af439cb00%
40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/85a8940b-0a4f-4de4-a568-050af439cb00%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/73fe7b9d-8161-45e6-aa1a-1ec381ef9093%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/73fe7b9d-8161-45e6-aa1a-1ec381ef9093%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/CAF_B3ddkpq9VGmNbZ82fcOqEjkft8L83a0WPARku_0LE_CCf2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Mcollective puppet-agent doesn't execute commands from custom facts
I've did more checks. I've updated aws api. Now command looks like:
aws ec2 describe-tags --filters Name=resource-id,Values=instance_id |
grep Role | /bin/cut -f5
Custom and external facts with this string still not works. Facter see it's
ok, but mcollective - doesn't.
I've created cronjob that run this command and send value to file. Created
external fact that cat file and echo role=$role. Mcollective worked fine.
On Saturday, August 2, 2014 9:57:07 PM UTC+3, Maxim Nikolaev wrote:
Hello
I met following issue with mcollective puppet agent.
I have custom fact that read tags from AWS cli and transform them to facts.
Facter.add(role) do
setcode do
iregion = Facter.value(ec2_region)
Facter::Util::Resolution.exec(ec2-describe-tags --region #{iregion} -O
KEY -W SEC_KEY --filter \resource-id=$(ec2-metadata -i | cut -d \ \
-f2)\ --filter \key=Role\ | cut -f5 -)
end
end
When I run facter from instance aor puppet agent from instance itself -
everything working fine.
When I run pupper runnonce from mcollective server - it doesn't read this
fact and apply only common manifest.
I checked several times and found, that if I set static file with role and
use external fact like:
#!/bin/bash
role=`grep Role /etc/server_facts | awk '{print $NF}'`
echo role=$role
Mcollective works fine. If Itry to use AWS cli command in script - again
fact doesn't wrk.
Have someone met such problem with mcollective? Can someone advise?
Puppet 3.6.2
Mcollective 2.5.3
--
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/db88a075-bf5c-4697-be6d-cb463397c436%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Mcollective puppet-agent doesn't execute commands from custom facts
Example of external fact that not worked:
#!/bin/bash
role=`/usr/bin/aws ec2 describe-tags --filters
Name=resource-id,Values=instance_id | grep Role | /bin/cut -f5`
echo role=$role
Fact see this, but mcollective doesn't get.
On Saturday, August 2, 2014 9:57:07 PM UTC+3, Maxim Nikolaev wrote:
Hello
I met following issue with mcollective puppet agent.
I have custom fact that read tags from AWS cli and transform them to facts.
Facter.add(role) do
setcode do
iregion = Facter.value(ec2_region)
Facter::Util::Resolution.exec(ec2-describe-tags --region #{iregion} -O
KEY -W SEC_KEY --filter \resource-id=$(ec2-metadata -i | cut -d \ \
-f2)\ --filter \key=Role\ | cut -f5 -)
end
end
When I run facter from instance aor puppet agent from instance itself -
everything working fine.
When I run pupper runnonce from mcollective server - it doesn't read this
fact and apply only common manifest.
I checked several times and found, that if I set static file with role and
use external fact like:
#!/bin/bash
role=`grep Role /etc/server_facts | awk '{print $NF}'`
echo role=$role
Mcollective works fine. If Itry to use AWS cli command in script - again
fact doesn't wrk.
Have someone met such problem with mcollective? Can someone advise?
Puppet 3.6.2
Mcollective 2.5.3
--
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/a1b3b84a-a58b-46ed-8ce6-ffba7225abf5%40googlegroups.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
