Difference between revisions of "Hiera Example"

From stoney cloud
Jump to: navigation, search
(explain a bit what this is)
 
(2 intermediate revisions by one other user not shown)
Line 18: Line 18:
 
   - "ou=virtual machines,ou=services?sub?(&(sstNetworkHostName=%{::hostname})(sstNetworkDomainName=%{::domainname}))"
 
   - "ou=virtual machines,ou=services?sub?(&(sstNetworkHostName=%{::hostname})(sstNetworkDomainName=%{::domainname}))"
 
   - "ou=software stack,ou=configuration?sub?(uid=%{::rzUid})"
 
   - "ou=software stack,ou=configuration?sub?(uid=%{::rzUid})"
 +
  - "%{::clientcert}"
 +
  - "%{::custom_location}"
 +
  - common
 +
</pre>
 +
 +
<pre>
 +
---
 +
:backends:
 +
  - json
 +
:json:
 +
  :datadir: /etc/puppet/hieradata
 +
:hierarchy:
 
   - "%{::clientcert}"
 
   - "%{::clientcert}"
 
   - "%{::custom_location}"
 
   - "%{::custom_location}"
Line 26: Line 38:
 
* This is an example of how a hiera config file might look with an mock ldap backend. The backend in question still needs to be found or written.
 
* This is an example of how a hiera config file might look with an mock ldap backend. The backend in question still needs to be found or written.
 
* mapping from a DN to directory structure would be nice, so we would rather have to write: ''ou=virtual machines/ou=services'' instead to be compatible with the already existing yaml/json backends or something different entirely
 
* mapping from a DN to directory structure would be nice, so we would rather have to write: ''ou=virtual machines/ou=services'' instead to be compatible with the already existing yaml/json backends or something different entirely
 +
* this needs to take into consideration that puppet expects keys to be defined in a way to enable implicit parameter injection in parameterized classes
 +
* existing ldap backends for hiera: [https://github.com/hunner/hiera-ldap], [http://forge.ircam.fr/p/hiera-ldap-backend/]
 +
* we should probably aim at integrating this in hiera-2 with regards to ARM-8 and the already imlemented ARM-9
 +
* I'm not convinced that we should not just grab all this data from the [[stoney_core:_REST_API]] and use that as an integration point for puppet.
  
 
[[Category: Documentation]]
 
[[Category: Documentation]]

Latest revision as of 15:33, 28 March 2014

---
:backends:
  - ldap
  - yaml
  - json
:ldap:
  :url:ldaps://ldap.stoney-cloud.org:636/
  :binddn:cn=Manager,dc=stoney-cloud,dc=org
  :bindpw:secret
  :basedn:dc=stoney-cloud,dc=org
:yaml:
  :datadir: /etc/puppet/hieradata
:json:
  :datadir: /etc/puppet/hieradata
:hierarchy:
  - "ou=virtual machines,ou=services?sub?(&(sstNetworkHostName=%{::hostname})(sstNetworkDomainName=%{::domainname}))"
  - "ou=software stack,ou=configuration?sub?(uid=%{::rzUid})"
  - "%{::clientcert}"
  - "%{::custom_location}"
  - common
---
:backends:
  - json
:json:
  :datadir: /etc/puppet/hieradata
:hierarchy:
  - "%{::clientcert}"
  - "%{::custom_location}"
  - common

Notes:

  • This is an example of how a hiera config file might look with an mock ldap backend. The backend in question still needs to be found or written.
  • mapping from a DN to directory structure would be nice, so we would rather have to write: ou=virtual machines/ou=services instead to be compatible with the already existing yaml/json backends or something different entirely
  • this needs to take into consideration that puppet expects keys to be defined in a way to enable implicit parameter injection in parameterized classes
  • existing ldap backends for hiera: [1], [2]
  • we should probably aim at integrating this in hiera-2 with regards to ARM-8 and the already imlemented ARM-9
  • I'm not convinced that we should not just grab all this data from the stoney_core:_REST_API and use that as an integration point for puppet.