On Friday, January 29, 2016 at 9:50:50 AM UTC-6, Gareth Humphries wrote: > > ENC is the end game, but we have legacy hosts this has to work on. Right > now I have site.pp which has a list of unpleasant regexes and an 'include > role::<whatever>' stanza for each. I could put '$role=<something> ; > include role::$role' in each of them instead, but I would have to do that > in every single case, which I'm trying to avoid. > >
I think if you had put the same amount of effort into porting those legacy node regexes to an ENC then you'd probably be done by now. In fact (no pun intended), you could perhaps even more easily pull the node regexes out to a top-level statement or block at the beginning of your site.pp that assigns a value to the role variable. > External facts work, but not on the first run. > As far as I know, external facts work even on the first run, just like all other facts. What would not work on the first run is using Puppet to manage the external fact file as a normal file, but you can bootstrap that process by dropping the appropriate file into place manually. You could even drop in a standard file that assigns a role that means "I don't know my own role", and let Puppet take it from there by updating that file as appropriate (and probably not doing much else on that first run). As I describe below, however, even that's probably unnecessary. In any case, something along these lines would still be a great deal better than parsing the node's catalog to compute the fact value, as you started out describing. You could seed nodes with initial catalogs, just as you could seed them with external fact files, to work around the first run problem, but an external fact file would be much simpler to build and maintain, and the external fact facility is a public interface exposed by Puppet. The catalog file format is an internal interface. > Because facts get loaded before catalog compilation, the host doesn't > know what to set that fact to until it already has a catalog - a little > bit chicken-and-egg. > If i'm relying on the role fact to get data out of hiera, I need that fact > available first run or compilation will fail. > Nonsense. In the first place, let's be clear: the catalog builder knows only about the *variable* $::role. It neither knows nor cares how that variable is assigned its value (if indeed it is assigned any value), so you do not specifically need a fact. In the second place, it cannot be too hard to condition evaluation of your site manifest on whether $::role has been assigned a non-empty value. You could certainly make it build and deliver a bootstrapping catalog in the event that no $::role variable is defined. Moreover, relying on your nodes themselves to tell you what configuration they are supposed to have is dreadful, at least from a security perspective. This exact problem is why ENCs override nodes with respect to environment assignment. > > Perhaps the set-the-variable-everywhere approach is going to be the > solution, i was just hoping to find a way that doesn't require that. > > I suppose by that you mean putting an assignment statement in each node block. I don't think that's actually so bad, but it's also not among the things I proposed. Making your ENC do the job would probably be best, and I still don't understand why that should be a big problem -- even if you have to write a simple ENC from scratch. If all it has to do is assign roles to nodes then your existing site manifest already has most of the logic you need. 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/bfeb597d-a7fb-45ae-a323-c6ccfb6478af%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
