Tom,
Thanks for you reply. I have already shared this with Gary, but i think it
is worth to make it here too.
Gary says that 'sysclass' and 'classes' are facts he sets, so this
explains why in my case they are being ignored. In any case, what I really
want is to control that from hiera completely.
As I understand it, the node in-director hiera.rb that is then later used
as a node_terminus = hiera in teh puppet.conf, does a preliminary lookup in
hiera to discover hostnames, classes, etc?
Is that correct?
If not, how can I make it happen?
I am going to paste part of teh email I wrote to Gary:
_____
I understand the facts are retrieved from the hosts. I do that to query
states of applications, sudoers, versions of certain software. Including
'tags' in the system you want to manage is always something tempting, but
you would have to add that information in the first place.
The question is: Where do I say that host1 should subscribe to classes
'basic' and 'app1' and to environment 'dev'?
Do you set that in a plain text file in the same host1?
What I want to do is to store that information in hiera:
host1.yaml
---
classes:
- basic
- app1
env: dev
param1: valuea
param2: valueb
By looking at your hiera.rb, you put together the facts from facter and add
the ones you discover form hiera, is that correct?
What do I need to read to start making changes in Gary's hiera.rb so I can
classify nodes in hiera, and not from external facts?
What I have at the moment is:
site.pp which contains things like:
stage {"basic": before => Stage[main] } # this lets me make sure that
basic is applied before any other
node default {} # this is to let ENCs as an entry point, as I understand it
node 'host1.domain.com' { class {basic: stage => basic} class { app1: env
=> "dev"}} # here we pass env as a parameter, we could pass other
parameters too.
this allows me to have structures to control what files get delivered such
as:
Production and development are Puppet file service locations:
[production]
...
path /opt/puppet-prod-files # under version control, owned by
operations
[development]
...
path /opt/puppet-prod-files # under version control, owned by
development
file { '/path/to/file/filename':
source => [
"puppet:///production/app1/$env/filename-$hostname",
"puppet:///production/app1/$env/filename-$env",
"puppet:///development/app1/$env/filename-$hostname",
"puppet:///development/app1/$env/filename-$env",
"puppet:///development/app1/$env/filename",
],
}
Form top to bottom granularity, giving production precedence. This allows a
directory tree that is under a couple of git repos, development is RW for
developers of each app and production is owned by operations.
This works well, but now developers want to control the RPM version that
gets installed to each environment (and maybe control it by host) and also
choose what hosts are members of each environment. One option would be to
give them access to site.pp or use includes. But that means giving them too
much and the possibility that it breaks often. Also I think it is a good
idea to separate code and data.
My final goal is something like this:
Puppet manifest:
$env = hiera("env")
$app1_version = hiera("app1_version")
app1/host1.yaml # granular settings for hosts
---
classes:
- basic
- app1
env: dev
app1_version: 3.1 # for env override
app1/dev.yaml # settings for env
---
app1_version = 3.0
There is nothing that stops me using this as a combination with hiera. I
can declare nodes like that and assign classes and parameters, and do the
rest with hiera. I crossed my main where to store the classification
information, with tag files in the hosts or centrally. Both have
advantages, but then a bigger reason came:
I am required to give development groups control of the environment in this
fashion:
By manipulating a plain text files, stored in version control, developers
should be able to manipulate:
- environment (hope to do with hiera)
- application versions (hope to do with hiera too)
- make changes to files (I already do by setting the env manually)
- decide configuration files granularity (the source array takes care of
that)
Bottom line: do you think it would be possible to retrieve 'env' from hiera
and populate it as a fact before it compiles the catalogue? If hosts are
looked up first in the hierarchy, can it use it to fall to the next node
in the hierarchy depending on that?
hostname = host1
and hierarchy:
:hierarchy:
- basic
- prod/%{application}/%{hostaname}
- prod/%{application}/%{env}
- prod/%{application}/default
- nonprod/%{application}/%{hostaname}
- nonprod/%{application}/%{env}
- nonprod/%{application}/default
*Chicken and egg problem*: how do I tell what %{application} is, if we are
not there yet?
Puppet discoveres facts on:
hostname = host1
Start.
Read data/prod/app1/* << it does NOT finds
matching hostname so it continues
Read data/nonprod/app1/host1.yaml << finds matching hostname and
gets classes and env
Read data/{nonprod,prod}/app{N}/host{N}.yaml <<< no more host1.yaml
files are to be found, no more data gathered
At this point hiera should know: classes = basic, app1 env = dev
Read data/nonprod/app1/dev.yaml <<< finds matching env, so it
gathers environmental settings if not overridden by host. app1_version = 3.0
Read data/{nonprod,prod}/app{N}/{ENV}.yaml << no more data gathered, as
there are no more matches.
hostname: host1
classes: basic, app1
env: dev
app1_version: 3.0
END
It seems that the problem basically is that with hiera, the classification
would happen AFTER the facts have been gathered, and the functions are
called to retrieve values.
I understand Gary's node indirector hiera.rb should get those lookups
done before the catalogue is compiled, giving then the desired effect.
What I need help with is:
- How do I shuffle my hierarchy so the lookups are done in the correct
order?
- Do I have to modify the node indirector created by you to give the extra
flexibility I need.
- And if so, where do I start?
Any ideas?
On Thursday, 27 September 2012 00:58:11 UTC+1, Thomas Linkin wrote:
>
> Guillem,
>
> I'm a little unsure of what you are trying to do with hiera. I think
> you're saying you want hiera to provide facts that you can use to then do
> lookups in hiera. I think this is a little bit of a chicken and egg style
> issue.
>
> I worked with Gary Hetzel on creating this ENC originally. I'd be happy to
> help you understand how to work his ENC, in case he has not been very
> available.
>
> Would you mind trying to explain what you're trying to achieve in more
> detail, I'd be happy to help!
>
> Thanks,
>
> -Tom Linkin
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/6qRv60YeMMkJ.
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.
