Hi John, Sorry for my late answer, right now I'm pretty busy. ;)
On 02/12/2015 15:18, jcbollinger wrote: > On Tuesday, December 1, 2015 at 11:26:15 PM UTC-6, François Lafont wrote: > > >> No, no. You can see >> http://puppet-on-the-edge.blogspot.fr/2015/01/puppet-40-data-in-modules-and.html >> >> With puppet 4, the "data philosophy" has changed. >> >> > I think "the data philosophy has changed" is a bit of an overreach. Two > things relevant to the current discussion have happened: > > 1. Puppet has adopted a data-in-modules mechanism into the core. This > has been long desired, and was available -- in different form -- as a > third-party module for Puppet 3. This, I already knew about. > 2. Puppet has added a mechanism to write custom functions in Puppet DSL, > including such functions as underpin the data-in-modules mechanism. This, > I had overlooked. > > None of that impacts my primary thesis, however. It still is impossible to > reliably predict what value a class parameter of an as-yet undeclared class > would take if that class were declared later, by unspecified means. You > can determine what value Puppet would choose via automated data binding, > but even supposing that yields a value at all -- it does not need to do -- > you cannot, in general, be certain that automated data binding is the > mechanism that ultimately will be used to set that parameter's value. That > is, you cannot, in general, predict what value a class parameter *will *take. > If you are willing to ensure that the class is declared, however, then you > can easily determine what value any of its parameters *does* take. Yes, you are absolutely right and your explanations show me that I was not precise enough when I have described my question. Sorry for that. I will try to fix it. 1. My question was in fact only about _public_ classes of my modules. 2. These classes are _always_ called via "require" or "include", never with parameters. (The only case where I can call sometimes classes with parameters is when a class in a module calls another private class of the same module.) So I fact my question is, for a node, the ENC will trigger this puppet code: # Only "include" or "require". include moda include modb include modc::fooc include modc::barc include modd::food include modd::bard include mode etc... and I would like to have the default value of ::modb::param equal to the value of the parameter ::moda::param. And I think it's possible (if 1. and 2. are satisfied) with this code in ./modules/modc/functions/data.pp: function modb::data { # We assume that the type expected here is a non-empty string. $param = lookup('moda::param', String[1], 'first') # code... { ... modb::param => $param, ... } } And mabe (but I'm not completely sure on this point), it could be a good idea to put in ./modules/modb/metadata.json a dependency ("modb depends on moda"). But I have lot of doubts on this point...? John, are we agreed in these conditions? > If you conceive a module to be in a position to control or even to know > whether and how a class from a different module is declared, then that's a > strong signal that you should combine or refactor your modules. If you > think one module has need for direct access to in-module data of a > different module, then that is also a signal that you should combine or > refactor. And in the conditions which I have described above, do you still think that a refactor is needed? According to me, 2 modules moda modb can be independent but sometimes it can be relevant (and handy) that the default value of modb::param is equal to the value of moda::param, no? For instance for the password shared between a server and the clients ie "server::pwd" and "client::pwd". Sorry again for my lack of details in my previous posts. François 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/56623C94.2000206%40gmail.com. For more options, visit https://groups.google.com/d/optout.
