Difference between revisions of "Hiera Example"
From stoney cloud
| [unchecked revision] | [unchecked revision] |
(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.
