-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi John
Thank you for your thoughts on this. On 05/15/2013 07:52 PM, jcbollinger wrote: > I'm not sure what you mean by "overwrite the anchor". In defaults.yaml I set bar: &bar 1 foo1::bar: &bar foo2::bar: &bar And for examlpe in hosts/mymachine.yaml only bar: &bar 2 So when it tries to set foo1::bar for mymachine it would use the anchor from mymachine.yaml and ignore the one in defaults.yaml. overwrite isn't probably the right word here yes. > 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. I know what you mean, but this ends in more global variables or some sort of singleton construct (steward) and I have no way of telling in hiera what classes in Puppet get influenced when I change this global variable. I would have to grep the whole code after this variable or I would have to hand them over to class parameters in some central location, which is just another place for the same thing I try to do in hiera directly with anchors but with one more layer which adds to the complexity. On the other hand we already have a class which seams to be a good place for this and I was probably just too stupid not to see that :-) I just realized I did not make clear what I try to achieve with this. The goal is to improve the visibility about where the data comes from and where it is used. > 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. I'm aware about that possibility, that's how we used hiera in puppet until now. We have hiera calls everywhere, in the middle of classes, templates, defines. And it is really hard right now to find out what changes if I manipulate the data. I think using variables only trough class parameters has some benefits when I comes to the visibility I mentioned earlier. The anchor thing was one solution I tried to come up with. But I think you have convinced me already to drop it again. Thanks again for your insights. Greetings Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGUy6oACgkQc2hfmdKpdfXoXACdG1/8lbX0Me05Q8yYLxl9jIue PZYAnRF9AcxXS9H1kiz09hf2xcJHuTSn =QwR8 -----END PGP SIGNATURE----- -- 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.
