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.

Reply via email to