It seems a very clever approach!!!
If it works could be the approach for not having dependency.
I do not agree that the two module are dependend, they just depend on the
same data, but given the data should be able to work on their own.
This problem is also mine in trying to design modules that do not require
people to have knowledge of other modules.
This approach enables to place all possible common data in the external
file and using hiera to decouple the stuff.
So on the module usage description people will just be asked to set the
files accordingly and the possible common data is referenced by hiera.
could the data be protected in some way? just not to have maby common
password written in clear?
Luca
Il giorno mercoledì 28 agosto 2013 02:26:41 UTC+2, François Lafont ha
scritto:
>
> Le 27/08/2013 22:49, jcbollinger a écrit :
>
> > Your modules are not independent in any case. The data dependency is a
> > symptom, not the root issue.
>
> Yes, you are right.
>
> > To answer more generally, since you started by posing a rather general
> > problem, where you have a bona fide configuration dependency, it is not
> > wrong for one module to depend on another. Real systems are composed of
> > multiple interdependent pieces, so it is natural for your models of them
> to
> > contain dependencies. You can shift them around to various places and
> > forms, but you cannot omit them and still have anything of much use.
>
> Ok, I understand, impossible to escape real dependencies, that's life.
>
> > One place you did not mention, to which you could shift the dependency
> > modeling, is your data. For example, lift your 'community' key to the
> top
> > level of your YAML data, consolidating all copies of it. Then have any
> > class that needs that particular key just load it.
>
> Very good idea. In fact, I saw the things with an oriented object
> approach: a
> class must know its data.
>
> > I don't think there is a clear, universal right answer here. My best
> > advice is to find where each datum belongs, and put it there.
> Coincidental
> > data duplication should not concern you overmuch, but do avoid
> duplicating
> > data for the purpose of presenting a false semblance of independence.
>
> Ok, I keep theses advices in my mind:
> - no duplication of data
> - define clearly where each datum belongs and put it there.
>
> I think it's a good idea to border the dependency on the data and not in
> the puppet code.
>
> I thought about another way with the extlookup function.
>
> ---
> snmp:
> community: extvalue_community
>
> monitoring:
> community: extvalue_community
>
> And in a common.csv file:
>
> extvalue_community,abcd1234
>
> Then:
>
> class snmp {
>
> $snmp = hiera_hash('snmp')
> $community = extlookup($snmp['community'])
>
> # and the rest of the class...
>
> }
> class monitoring {
>
> $monitoring = hiera_hash('monitoring')
> $community = extlookup($monitoring['community'])
>
> # and the rest of the class...
>
> }
>
> I don't know if it's good method.
>
> Thanks for your help John.
>
> --
> Francois Lafont
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
