[Puppet Users] Hiera relationships

2012-08-09 Thread Wolf Noble
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.



Re: [Puppet Users] Hiera relationships

2012-08-09 Thread Dan White
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.



Re: [Puppet Users] Hiera relationships

2012-08-09 Thread Wolf Noble

On Aug 9, 2012, at 5:15 PM, Dan White y...@comcast.net
 wrote:

 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].

Nope ;)


 In an effort to make a serious response:

 I feel you may be using the wrong tool for the job.

quite possibly… I actually came up with this as a straw man example of a way to 
say 'this other module's hiera values may constrain or conflict with mine'

 If, as in your example, snmp and tripwire are interrelated, that should be 
 handled by your class/resource definitions.

*nod* I get that. I was thinking that having the ability to constrain 
possibilities of parameters or define conflicts in the hiera function of a 
module might make the 'shipping a module with hiera parameters to the forge for 
community use at large' easier.

I have absolutely no attachment to the idea; if people thought the idea was a 
good one, great! I done helped a bit!
but if not... well… I DID say I was asleep.

 How would you solve this problem in a version of puppet before hiera ?

Therein lies the problem, I think.
The issues of divergently sourced module cohabitation is a complicated one.

now with hiera, I was thinking having consistent, module-scoped namespacing 
would be a good thing, but then this scenario presented itself to my 
dreamspaced mind and I didn't really see a great way  around it.

 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 ?

Totally agree.. I don't know that there's a better answer than that. I just 
wasn't convinced that there's not, either.

 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:



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.