On Monday, December 16, 2013 10:38:27 AM UTC-6, Joseph Swick wrote: > > On 12/16/2013 10:59 AM, jcbollinger wrote: > > > > > > On Friday, December 13, 2013 3:56:50 PM UTC-6, Joseph Swick wrote: > > > > [...] > > > > What am I missing to get Puppet to evaluate the $resourceX_type > >> variables as a resource type [e.g: File, Service, etc.] to get this to > >> work? > > > > > > > > Puppet DSL does not provide such a feature. It is conceivable -- > likely, > > even -- that you could instead create a custom function to apply generic > > ordering constraints such as you want but you should beware that unlike > > relationships declared via the DSL, relationships applied via a function > > would probably be sensitive to manifest evaluation order. > > > > > >>> > > > > I suspect that the use case for the functionality you describe is not > > nearly so general as you suppose. Module portability is more typically > > approached in Puppet by using facts -- custom facts, if necessary -- to > > probe the relevant characteristics of the target machine, and by using a > > small number of higher-level alternatives to determine what to declare. > > > For example, it is common to use the $::osfamily fact to guide what > > declarations to make, coding appropriate specifics for each supported OS > > family. > > > > > > John > > > > Thank you for the reply. However, I think you may not be fully > understanding what I was trying to describe (or I didn't describe it > well enough). What I'm trying to do has nothing do do with resource > facts on the system within a module. We're already using various facts > to define which portions of the hieradata should be considered for a > particular node. I would like to ensure that the resources that get > defined as a result are created in the correct order when required. > >
On the contrary, you were clear about that the first time. You are looking for a general-purpose way to encode generic resource relationships in your hiera data. You cast the reason for wanting to do so in terms of module portability. As I wrote the first time, Puppet DSL+hiera does not support what you hope to do, though likely you could achieve it with the help of a custom function. The rest of what I wrote was basically a recommendation against doing it even with a custom function. I don't think it will serve your portability objective very well. 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/991cbf7b-103a-41ac-be99-4b79516ec5f9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
