Closed mcanevet closed 10 years ago
What would be the motivation?
R.I.Pienaar
On 20 Aug 2014, at 08:52, Mickaël Canévet notifications@github.com wrote:
Would it be possible to not limit the hiera lookups to the module namespace ?
— Reply to this email directly or view it on GitHub.
Well, for instance, to set components defaults at profile level so that we can use include
instead of class
.
Imagine a role that declares 2 profiles that manages 2 different web services, each profile may come with different apache defaults.
class myrole {
class { 'myprofile1': }
class { 'myprofile2': }
}
class myprofile1() {
class { 'apache':
server_tokens => 'Prod',
}
...
}
class myprofile2() {
class { 'apache':
server_signature => 'Off',
}
...
}
This will not work because of duplicate declaration of apache class.
This could be solved with data in modules not limited to module namespace and usage of include
instead of class
.
I'd say your profile should class{"apache": ...} while the rest just include. Or the myprofile1 class should take $server_tokens.
So if I don't limit it, what keys would you create to resolve this in your hiera data?
---
apache::server_tokens: Prod
---
apache::server_signature: Off
But this is not the only use case. We usually have a role level in our hierarchy so that we can set components values without exposing every component parameter to the profile. This works pretty well:
$role = hiera('role')
node default { class { $role: } }
---
:backends:
- yaml
:yaml:
:datadir: "/etc/puppet/environments/%{::environment}/hieradata"
:hierarchy:
- "nodes/%{::clientcert}"
- "roles/%{::role}"
- "common"
The problem comes when we want to use inheritance for roles:
class myrole inherit myparentrole {
class { 'myprofile1': }
}
Data of myrole
are looked up, but not the one of myparentrole
.
With data in module not limited to current module namespace, we could have roles modules that comes with data for components without exposing components params to profiles and inheritance would work. And I could remove "roles/%{::role}" from my hierarchy.
hmm, yeah I am not sure that'll work - it seems you'll need to know what the class doing the include'ing is called and then go look in that class. And it would be badly order dependent I think?
Not sure, I think its on the wrong side of the magical behaviour line tbh :)
Well, you're probably right... I guess the best solution to my problem is to expose the components params I require to the profiles so that I can configure the components from my role, remove role from the hierarchy and forget using data binding for this use case...
Would it be possible to not limit the hiera lookups to the module namespace ?