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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 <wnoble@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Aug 9, 2012, at 5:15 PM, Dan White <ygor@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 <wnoble@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.