On Wednesday, July 18, 2012 4:09:42 PM UTC-5, Trevor Vaughan wrote:
>
> So, I was following the thread "how to conditionally add users to a 
> virtualized group?" and had a bit of a realization that I'm not quite 
> sure why Hiera is a better backend than LDAP. 
>
> Hiera: 
>
> - Stores hierarchical data locally on your system 
> - Uses YAML 
> - Integrates with puppet 
>

That's not actually a very good description of Hiera.  It describes the 
combination of the built-in data backend shipped with hiera, whose use is 
optional, with the Puppet integration layer, which is packaged separately.  
None of it describes the hiera core, which I would describe as a framework 
for selecting and combining data from various sources based on a 
user-defined priority hierarchy.
 

>
> LDAP 
>
> - Stores hierarchical data across potentially multiple systems (think 
> puppet master scaling and data sync) 
> - Uses LDIFs 
> - Needs some glue code written 
>
> However, both are hierarchical databases based on 'read often/write 
> rarely' principals. 
>

No, I don't think they're actually very comparable.  The Hiera core is an 
hierarchically-oriented data access framework, compatible (in principle) 
with a wide variety of databases.  The two are not on the same level.  
Indeed, as you acknowledged, it would be feasible to write a hiera back-end 
that accessed data from an LDAP directory.  That would be comparable to 
hiera's YAML back-end, but not to the hiera core.
 

>
> Besides the glue code to make LDAP do Hiera-like things, what are the 
> issues? It also seems that using a well known and supported system, 
> such as LDAP, would foster greater enterprise support (except in those 
> places where you have to spawn your own due to insane directory 
> admins).
>

I'm not saying that LDAP wouldn't be a good data repository for Puppet.  
You're quite right that it is well understood and widely deployed.  I am 
certain that there are LDAP backends out there for extlookup(), and perhaps 
also for Hiera.  There are probably also be custom data access functions 
for LDAP in some shops.  I don't think there are any fundamental issues 
blocking its use with Puppet.

On the other hand, LDAP is far too heavyweight to be viable as the singular 
primary data source for Puppet, and Puppet needs such a thing to make an 
ecosystem of modules viable.  
 

>
> And, yes, I know that a hiera back-end could be written to support 
> LDAP but that would just be an unnecessary data transference if I'm 
> reading it right.
>

I'm not sure what you mean by that, but the advantages of accessing LDAP 
via hiera include:

   1. Abstraction.  Module authors don't need to care where data comes from.
   2. Pluggability.  The LDAP back-end could be swapped out for a different 
   one. That's useful for testing, or for non-LDAP shops to use the same 
   modules as LDAP shops.
   3. Combining and overriding data.  Data packaged with modules or added / 
   overridden by admins don't need to be recorded in LDAP.
   
Depending on how you do your accounting, there may not even be any more 
layers in an hiera-based stack.  Any way around, getting the data into 
puppet means going through a Puppet custom function that wraps an LDAP 
client that gets data from your directory. 


John

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

Reply via email to