ripienaar / puppet-module-data

Hiera backend that stores data in a module
74 stars 43 forks source link

Don't limit lookup to module namespace #16

Closed mcanevet closed 10 years ago

mcanevet commented 10 years ago

Would it be possible to not limit the hiera lookups to the module namespace ?

ripienaar commented 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.

mcanevet commented 10 years ago

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.

ripienaar commented 10 years ago

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?

mcanevet commented 10 years ago
---
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.

ripienaar commented 10 years ago

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 :)

mcanevet commented 10 years ago

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...