On Friday, July 17, 2015 at 2:31:11 AM UTC-5, bjoern pohl wrote: > > Hi, > we're currently transforming some ugly perl-based management scripts > (which placed some config data on the client and then configured something > with it) to puppet. > > While it is definitely the best idea point to keep all that config data on > the master ( using hiera, puppetdb, etc..) i am currently looking for an > interim solution to incorporate some of this local config data into > centrally managed manifests/classes. > > Hiera is always using central hiera data while running the puppet agent > server-based and is not using any hiera files placed on the client by > default, is there some way to get around that ( perhaps with some kind of a > server->client precedence)? Hiera is installed on all clients. > >
Catalog building is performed on the master, therefore all hiera calls involved in catalog building -- including for automated data binding -- draw on the data present on the master (only). > I know that I could achieve something like that with custom facts ( > generating facts from those locally placed config files) but this is quite > a lot and would bloat up facter :) > Facts are *the* way for nodes to dynamically provide data to the master to inform catalog building. It is conceivable that you could build a custom function to provide some sort of network interface as an alternative, but it would probably be easier to just do the right thing by moving the data to the master. > > Or a more elegant way to get around that ( apart from putting that data > where it belongs: the puppetmaster :) )? > > If you need the data for catalog building, then there is no possible alternative to putting on the master, either once for all or dynamically in conjunction with each catalog request. There could be a bit of leeway around "on the master", in that you could perhaps rely on one or more network file systems to blur the distinction between "on the master" and "on the target node". Also, "in conjunction with each catalog request" doesn't necessarily mean using custom facts, although that would be the most straightforward implementation. A custom function or a custom Hiera back-end could also fit in this spot, given corresponding support on the agents. 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/242b9a3d-60a2-4c19-acee-29d59d825129%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
