Wow. My next reaction is, "Are you sure you woke up ?" But then I am a known and convicted joker and a registered paronomasiac [1].
In an effort to make a serious response: I feel you may be using the wrong tool for the job. If, as in your example, snmp and tripwire are interrelated, that should be handled by your class/resource definitions. How would you solve this problem in a version of puppet before hiera ? If one module wants a service running and another wants it stopped, there needs to be something like a common parameter or decision point over both modules to prevent a conflict. Does that make any sense or do I need to wake myself up to try for a better answer ? I am honestly trying to help out, but your statement of the problem is a bit confuzzled [2]. (1) http://en.wiktionary.org/wiki/paronomasiac (2) http://en.wiktionary.org/wiki/confuzzle “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) ----- Wolf Noble <wno...@datapipe.com> wrote: > I was asleep, and woke up thinking about a way to define a relationship > between the hiera parameters of multiple modules such that conflicts could be > avoided... > > The thought process was that if I set one value, say, the service enablement > parameter for snmp to 'stopped' in my tripwire module, that value could > conflict with the service parameter of the snmp module.. Which references a > completely unrelated hiera parameter > > > I thought about just using the same value for both, but that could be > confusing for sharing modules, as the pseudo-scope of hiera parameters ie: > > $modulename_parametername: foo > > snmp_snmp_enable: enable > tripwire_snmp_enable: stopped > > Would no longer be the rule, which, while I suppose there is no rule, (is > there?) this made the most sense to me, so I ran with it. > > I thought, sleepily: if there was some way for me to say there could be a > conflict which could be clearly stated in the hiera values, I think it might > make for easier module sharing/blending > > 'if this other parameter (bacon_crispness) exists and has the value of [ > crispy,burnt,raw ] that conflicts with me (breakfast_enjoyment) if the value > is true.' > > This could be furthered to override a stated value via a relationship : > Breakfast_enjoyment: true <~ unless (bacon_crispness) is [ crispy,burnt,raw ] > > Or to confine another parameter's values: > Breakfast_enjoyment: true ~> bacon_crispness: [ undef,chewy,thick,absent ] > > > > Is there any merit to this idea? > > In speaking with people who have tastyzombiebrains™ there was a concern that > this breaks the 'data only' model of hiera.. so perhaps the dependency logic > should live in the hiera function in puppet? or not at all… dunno.. > > Maybe I should have just gone back to bed? > > ________________________________ > > This message may contain confidential or privileged information. If you are > not the intended recipient, please advise us immediately and delete this > message. See http://www.datapipe.com/legal/email_disclaimer/ for further > information on confidentiality and the risks of non-secure electronic > communication. If you cannot access these links, please notify us by reply > message and we will send the contents to you. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
