Grokbase › Groups › Puppet › puppet-users › August 2012
FAQ
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 [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Dan White at Aug 9, 2012 at 10:15 pm ⇧
    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 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 [email protected].
    To unsubscribe from this group, send email to [email protected].
    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 [email protected].
    To unsubscribe from this group, send email to [email protected].
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Wolf Noble at Aug 9, 2012 at 11:13 pm ⇧

    On Aug 9, 2012, at 5:15 PM, Dan White 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 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 [email protected].
    To unsubscribe from this group, send email to [email protected].
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedAug 9, '12 at 5:29p
activeAug 9, '12 at 11:13p
posts3
users2
websitepuppetlabs.com

2 users in discussion

Wolf Noble: 2 posts Dan White: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase