On Monday, January 13, 2014 10:22:36 AM UTC-6, Ramin K wrote: > > > Stages should be treated as black boxes where you assume everything that > was suppose to happen in an earlier stage has already happened.
That's a good description. > You can > not notify to any resources from a resource in a later stage. Because that always forms a dependency cycle. If one resource declares that it notifies another then the notifier must be applied first. If the notifyee is in an earlier run stage then it must be applied first. Voilà, a cycle. > And it's a > bad idea to refer to any resources between any stage as you're almost > guaranteed to cause dependency cycles. Yes, as a generalization of the 'notify' case. Any resource reference that crosses run stage boundaries is either redundant or cycle-inducing. > This is why stages are only used > for a small subset of problems. > > I'm not much of a fan of run stages myself, though there are situations for which they do provide an advantage. Overall, though, there is nothing run stages can do that you cannot also do via ordinary resource relationships. At least in principle. > In your case I don't see any reason for zabbix to be in a stage. No > point in monitoring being up before the services it needs to monitor. > Remove stage => when you declare it and you should be fine though you > might need to fix ordering afterwards. > > Alternatively, put Class['redis'] in stage 'pre', too. Of course, that will just send you down a rabbit hole if there are other classes that need to be applied before Class['redis']. Aaaannd we're back to me not caring much for stages. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ad506371-58ef-4c9d-9e4c-0d7c672628bb%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
