Hi all,
I have thought myself of a #4 possibility, which could be defining the
hierarchy as:
- %{hostname}
- groups
- all
And then create a class called data::groups with a big IF/CASE inside:
class data::groups {
if 'green' in $::groups {
$var1 = 'whatever'
}
if 'blue' in $groups {
$var1 = 'happens'
} # and so on.
I would then have to define the $::groups variable somewhere, most likely in
the beginning of the default node, before any other Hiera() function is called.
The problem I have with this is that, when a machine belongs to more than one
group, some variables may be declared more than once, which will break the
compilation of the manifest. That's why I wanted Hiera for (and the
primary/secondary group hierarchy), so that I could do hiera_array() and add
values from all possible groups of machines.
The whole idea of this question is to keep the information of each node in the
minimum possible number of places. It is already awkward to have a "node"
section and a "data" (hiera) section, then having the group membership inside a
ruby script lost inside some module makes me feel bad about it. I would like to
have a reasonable way of managing groups of machines, where every group a
machine belongs to provides (adds) some information to the overall node state.
Adding values from inside the groups the machine belong to (for example,
authorized_keys or firewall rules, something easily done with arrays that can
be stacked with hiera_array()) should be easy.
Thanks!
Pablo
________________________________________
From: [email protected] [[email protected]] on behalf
of Gary Larizza [[email protected]]
Sent: Saturday, March 24, 2012 12:01 PM
To: [email protected]
Subject: Re: [Puppet Users] Plugins and Hiera
On second-thought, #3 would be out of the question if you wanted to use
%{primary_group} as a hierarchy level in Hiera. You will need to either write
a fact to determine the group based on something atomic about the system or do
something at provision time. Do you have this node-to-primary/secondary-group
mapping in a source of truth like a MySQL database? If so, then you could
utilize a Hiera backend to query this source of truth. There are Hiera-mysql
backends that will allow you to read from database tables, so this is also an
option. I would likely lean toward option #1, however.
Hope this helps.
On Sat, Mar 24, 2012 at 3:55 AM, Gary Larizza
<[email protected]<mailto:[email protected]>> wrote:
On Fri, Mar 23, 2012 at 3:42 AM, Pablo Fernandez
<[email protected]<mailto:[email protected]>> wrote:
Dear all,
This is a continuation of another thread, but I think the question diverged
enough to create a new one.
I have a hiera hierarchy like this:
:hierarchy:
- %{fqdn}
- %{secundary_group}
- %{primary_group}
- %{productname}
- all
And I need to define the secondary/primary groups as facts, on the nodes. Gary
has suggested me to use plugins, that they will provide the facts before puppet
runs... but I was thinking: for plugins to give facts, taken directly from
within the puppet code, puppet needs to run first, doesn't it?
So, I guess I could create a module and a ruby script:
- mygroups/lib/facter/addgroup.rb
And write some code in Ruby to call Facter.add(:primary_group).
My problem is (besides the fact that I know nothing about Ruby)... how do I
insert the values for primary_group and secondary_group inside that function,
within a simple puppet run?
I would ask how you could classify a node's primary or secondary group based on
looking at? Is there a file on disk that indicates its group? Will you use
its IP address? Hostname? Something like this?
It sounds like you want to use Puppet to place a file on the filesystem
indicating its primary_group, but that you want to Puppet to manage this file
(or you want to manage the data in Puppet itself). You have a number of
options here:
1. Use something atomic about the machine to determine its primary_group. If
you can say 'based on its IP address, it should be in this group' or 'based on
its hostname, it will be in THIS group', then write a fact to determine this
for you. Remember that in your custom fact you can do:
Facter.value(:ipaddress) or Facter.value(:hostname) to get a node's ipaddress
or hostname. This is the better method since it relies on something NOT
provided by Puppet to determine its group. The Facter fact would run before
the Puppet run, determine its group, and then you'd be fine. Most places I
visit do something like this.
2. Do something at provision-time. Do you already have a source of truth that
maps each node to a primary_group? In your kickstart before running Puppet you
could query this source of truth and create a file (to be read by a fact) that
would determine the primary_group.
3. Set it in the %{fqdn} level of the Hiera hierarchy. This is less-optimal
as you would need to create a YAML file for every node in your infrastructure
and set its 'primary_group' parameter in the YAML file. If you don't have a
source of truth that maps each node to a primary_group, and you can't determine
the group based on something ABOUT the node itself (as in case #1), then Hiera
can/will be your node/group source of truth.
Does this sound like what you need?
I guess I could use a file with the definitions, like /etc/facts.d/groups...
but that would require two puppet runs: one to create the file, and the second
that loads the facts.
I was thinking of a possible alternative... a module "mygroups" with
sub-classes, that I import from the nodes:
node 'blabla' { include mygroups::green }
And then in the module, make a mygroups/lib/facter/green.rb that does
Facter.add(:primary_group) = 'green' (or however you do it with Ruby). But how
do I make sure the module green.rb is loaded, but not the other modules that
will be there too?
Or maybe I could use parameters, that the plugin will recognize somehow?
I hope the questions are clear enough, because this is clearly not clean in my
head.
Thanks!
Pablo
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to
[email protected]<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]<mailto:puppet-users%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
