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.
External facts work, but not on the first run. 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. 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. On Friday, January 29, 2016 at 3:20:20 PM UTC, jcbollinger wrote: > > > > On Friday, January 29, 2016 at 3:29:29 AM UTC-6, Gareth Humphries wrote: >> >> Thanks Gav, >> >> It's a good idea, though on the surface I don't think it will work for us >> (we're trying to spin stuff up from a gold image using an ENC, and I think >> having an extra magic step in between is a greater evil than explicit >> declarations), but you've got me thinking down some other lines of >> automation. >> > > > If you're relying on an ENC, then isn't that ENC assigning roles to > machines? In that case, why do you need a fact? The ENC can inject > top-level variables that you can use exactly as you would use facts. > > More generally, if you have centralized knowledge of what role each > machine should have, then you should serve it centrally instead of storing > it on nodes and relying on them to feed it back correctly. Hiera would be > another option for doing that. > > I'm really having trouble understanding why you are approaching the > problem as you describe. If indeed you have a way to assign a role class > to your nodes without relying on the fact you're trying to create, then I > don't see why you need the fact. Moreover, I don't see why you need to > analyze catalogs to extract the value for such a fact, instead of making > Puppet itself manage the fact. If you rely on external facts > <https://docs.puppetlabs.com/facter/3.1/custom_facts.html#external-facts> > for the purpose, you can have your role classes manage an ordinary file on > agent-side file system to make that node provide any given fact on > subsequent runs. As a side effect, this could even prevent assigning > multiple role classes to the same node. Indeed, this is one path by which > you could arrange for nodes to provide the desired fact with their very > first catalog request, though again, I don't understand what purpose the > fact is supposed to serve. > > > > 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/d813a0e6-e040-49f6-9831-c811b8324096%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
