John,
Many thanks for your long reply, it is much appreciated. You have assured
me in teh conclusions and course of action and i am glad that my
appreciation of teh problem I have was not so far from the reality.
Thanks again.
Guillem
On Wednesday, 26 September 2012 16:52:19 UTC+1, Guillem Liarte wrote:
>
> This is the situation I have:
>
> All my hosts are the* same OS.*
> All my host are in the* same puppet environment,* so I cannot use
> %{environment}
>
> I have a module that sets all the *basic* functionality for the OS,
> resolution, authentication, security, packages, etc
> I have a module for each application hosted.
>
> At the moment all the 'data' is in Puppet, mostly in parametrised classes
> in site.pp.
>
> What I want to get is a hiera set-up that allows me to use this structure:
>
> :hierarchy:
> - global # source of application names (classes? modules?) and
> environments list
> - basic # data for the basic class
> - prod/%{application}/%{hostname} # hostname files for specific
> data
> - prod/%{application}/%{env} # environmental data for
> each application (module)
> - prod/%{application}/default # default data for an
> application
> - nonprod/%{sysclass}/%{hostname}
> - nonprod/%{sysclass}/%{env}
> - nonprod/%{sysclass}/default
>
>
> Then to have something like this under the datadir:
>
>
> #├── global.yaml
> #├── basic.yaml
> #├── nonprod
> #│ ├── app1
> #│ │ ├── common-integration.yaml << Alfresco common
> integration
> #│ │ ├── continuous-integration.yaml
> #│ │ ├── dev.yaml
> #│ │ ├── default.yaml
> #│ │ ├── host1.yaml
> #│ │ ├── host2.yaml
> #│ │ ├── performance.yaml
> #│ │ ├── qa.yaml
> #│ │ ├── test.yaml
> #│ │ └── uat.yaml
> #│ └── app2
> #└── prod
> # ├── app1
> # └── app2
> #
> # etc.
>
> In global.yaml
>
> ---
> :classes:
> basic:
> app1:
> app2:
> app3:
> app4:
> :env:
> test:
> dev:
> commonint:
> continuousint:
> dev:
> performance:
> qa:
> test:
> uat:
>
>
> in app1 default.yaml:
>
> ---
> classes:
> app1:
>
> app1_version: 'latest'
>
>
>
> in app1 dev.yaml:
> ---
> app1_version: '3.0'
>
> If I wanted host1 and host2 to be part of dev for app1:
>
>
> host1.yaml:
> ---
> classes:
> basic:
> app1:
> env:
> dev:
>
> maybe in host2 I want to override version too:
>
> host2.yaml
> ---
> classes:
> basic:
> app1:
> env:
> dev:
> app1_version: '3.1'
>
>
> So in short, I would like hiera to be a source of facts, where I can get
> information that feeds Puppet in order to classify the nodes and to feed
> the parametrised classes.
>
> I recently found this blog entry:
>
> http://garyhetzel.com/2012/04/12/hiera_as_a_puppet_enc
>
> Gary has been very helpful and I have got an idea of what needs doing. I
> can query all the data the way I want using the hiera command. Something
> like these:
>
> hiera app1_version sysclass=app1 env=dev
>
> Returns the expected '3.0' and if I query by adding teh host:
>
> hiera app1_version sysclass=app1 env=dev hostname=host1
>
> I get 3.1. Cool!
>
>
> Example using Gary's approach:
>
> /opt/puppet-data/nonprod/hieratest/default.yaml
> ---
> classes: hieratest
> env: hieratest_default
>
> /opt/puppet-data/nonprod/hieratest/host1.yaml
> ---
> classes:
> hieratest:
> env: 'hieratest_performance'
>
>
> # hiera env sysclass=hieratest --debug
> DEBUG: Wed Sep 26 16:40:46 +0100 2012: Hiera YAML backend starting
> DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking up type in YAML backend
> DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking for data source global
> DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking for data source basic
> DEBUG: Wed Sep 26 16:40:46 +0100 2012: Looking for data source
> nonprod/hieratest/default
> DEBUG: Wed Sep 26 16:40:46 +0100 2012: Found env in
> nonprod/hieratest/default
> hieratest_default
>
> # hiera type sysclass=hieratest hostname=host1 --debug
> DEBUG: Wed Sep 26 16:40:57 +0100 2012: Hiera YAML backend starting
> DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking up type in YAML backend
> DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking for data source global
> DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking for data source basic
> DEBUG: Wed Sep 26 16:40:57 +0100 2012: Looking for data source
> nonprod/hieratest/host1
> DEBUG: Wed Sep 26 16:40:57 +0100 2012: Found env in nonprod/hieratest/host1
> hieratest_performance
>
>
> But when it comes to use this in Puppet the results are not as I expect,
> nothing happens, it just does a run no classes are used. I see that the
> basic class custom facts are loaded, but nothing gets executed, as if the
> catalogue for host1 would not include it.
>
>
> In Puppet I expect to just have:
>
> in site.pp:
> node default {}
>
> And then in each application’s init.pp:
>
> $env = hiera("env") << this allows me to get the right config files
> (with are maintained in a git repo)
> $app1_version = hiera("app1_version") << this allows me to set the right
> RPM version (from satellite/spacewalk/RHN)
>
> As per Gary's post, I can use hiera as node terminus, and so it is set in
> puppet.conf.
>
> I would like to make emphasis in this: Gary's hiera as an ENC works, but
> for a more simple scenario than the one I am proposing, if I only wanted to
> classify Classes and Hosts, it does work fine. Where I have not been able
> to succeed is in adding an 'env' layer after the application (classes,
> organised in modules).
>
> I can get to organise things solely by host-name too (I could have a huge
> list of hundreds of hosts and manage that), but what I need is to be able
> to split them into directories as these are managed by each team
> responsible for the applications.
>
> I a a beginner in ruby, and I am willing to help as much as I can to get
> the use of hiera as an ENC as much as possible.
>
> Do I have the right approach given the requirements?
> Is there a better approach to this one?
>
>
> Kind regards,
>
> Guillem
>
--
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/-/QhOEBYWgOCcJ.
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.
