On Wednesday, May 15, 2013 8:43:39 AM UTC-5, Andreas Zuber wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello > > I'm in the progress of refactoring a lot of our old puppet manifests > to finally get rid of all this global variables (we where young and... ) > > Now some of the settings are used in more then one class. > > Example for one domain in hiera: > > sssd::ldap_servers: > - 'ldap://ldap1.example.com/' > - 'ldap://ldap2.example.com/' > > openldap::client::servers: > - 'ldap://ldap1.example.com/' > - 'ldap://ldap2.example.com/' > > which i could simplify with anchors: > > ldap_servers: &ldap_servers > - 'ldap://ldap1.example.com/' > - 'ldap://ldap2.example.com/' > > sssd::ldap_servers: *ldap_servers > openldap::client::servers: *ldap_servers > > A bit less redundancy than before, but there is still another problem. > If i want to set something else in a different domain i have to copy > the whole thing. > > So if i add a new class i have to think of all the domains and other > levels where i overwrote that stuff and add that class. > > It would be really nice if there was a way to only overwrite the > anchor so i don't have to copy all the classes that use the value to > the other YAMLs. From what i see in the hiera code this is not > possible at the moment. >
I'm not sure what you mean by "overwrite the anchor". > > Or is this a bad idea in general? > > I think the bad idea here is to present fundamentally the same data via different, parallel paths. There is no sense of an authoritative source, and the resulting muddle is a natural result. If your sssd class and your opernldap::client class inherently must have the same list of LDAP servers in order for a correct configuration to result, then that should be modeled in Puppet, not made a requirement for the data maintainer to ensure. In that case hiera should define a single (both physically and logically) LDAP server list to any given client. On the Puppet side, either all classes that need the data should load it via the same key(s) (because it is and must be the same data), or else one designated class should load the data and serve as its steward, and others that want it should get it from that class. Anchors simply don't enter into it there. On the other hand, if there is no inherent constraint that the two classes use the same LDAP server lists, then data duplication on the hiera side is coincidental and perfectly appropriate. In that case I would advise you to avoid giving a different impression, as using a combined physical representation through anchors might do. Note, too, that hiera data doesn't have to be accessed via automatic class parameter binding, and indeed that classes don't have to be parameterized. Since Puppet 3, I have relaxed my stance toward parameterized classes (which was once highly critical), but I still don't think they provide much of a win. I would rather load external data via explicit hiera() calls -- or via hiera_array() or hiera_hash() calls where that is useful, which automated parameter binding cannot provide. In this case, doing so would remove the false perception that the same data need to be provided via different keys. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
