On Friday, December 4, 2015 at 7:23:44 PM UTC-6, François Lafont wrote:
> 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?
>
I'm not sure where my agreement factors in. Your conditions are whatever
they are, or at most what I can persuade you they should be.
I still maintain that you are contemplating an inappropriately tight
coupling between your modules. You likely can come up with a list of
restrictions sufficient to ensure that there is a method to determine what
value a parameter of class ::moda *would* take in the event that that class
were declared, other than actually declaring the class and checking what
value it actually *did* take. You have not yet stipulated enough
conditions for that, however: you would at least need to account also for
the possibility of the value depending on Hiera interpolation tokens that
in turn depend on the 'calling' class or module.
> > 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?
>
>
I think the specific conditions are irrelevant to the main thrust of my
position. The fact that your code and data would need to comply with a
relatively complex set of conditions for what you propose to be workable at
all is one of my primary arguments. I predict that taking on such a set of
extra requirements will cause you grief, more likely sooner than later, and
I urge you to devise another way to accomplish your objective.
If you insist on proceeding in this general direction, however, then I'd
suggest employing a variation on the Params Class pattern. Create a class
::moda::params and give it a parameter or ordinary class variable
$::moda::params::param that will serve both as the (definite)
initialization value for $::moda::param and as the default value for
$::modb::param. This will require that $::moda::param be made an ordinary
class variable instead of a class parameter, so that it can never take a
value different from $::moda::params::param. It will also require that
class ::modb inherit directly or indirectly from class ::moda::params. In
Puppet 4, $::moda::params::param can receive its value in any way you see
fit, including automated data binding (if you opt to make
$::moda::params::param a class parameter), but you would create an
evaluation-order dependency if every you used a resource-like declaration
of it, either directly or via an ENC. Class ::moda::params would avoid
declaring any resources so that declaring it (as classes ::moda and ::modb
would both need to ensure happens) will not directly affect the target
node's state.
If you're following closely you will observe that that solves the problem
by adding a layer of indirection. You may also recognize that class
inheritance across module boundaries is considered poor practice by many;
this should be taken as further support for my argument that your proposed
modules are too tightly coupled.
> 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".
>
>
No. If a class of module modb depends on moda for a default value of one
of its parameters, then for that very reason, modb is *not* independent of
moda, neither conceptually nor code-wise. If you want two *independent*
modules to share data, then they must each draw it from the same external
source, rather than one drawing it from the other.
Drawing from the same source can be accomplished in a variety of ways.
Indeed, my params class suggestion would be such a technique if the params
class belonged to a module that was neither moda nor modb. You could also
do it by defining an Hiera key that must be the ultimate source for the
data, and ensuring that lookups for that key never fall back on
module-specific data. There are other alternatives.
In fact, if what you wanted were what you actually just wrote -- "the
default value of modb::param is equal to the value of moda::param" -- then
although that establishes a dependency between modb and moda, it
nevertheless could serve as a pattern for a shared data source.
Specifically, you could then use ::moda itself as a params class for ::modb,
or in some related way rely directly on $::moda::param for the data, as
indeed I observed in an earlier message. But that's *not* what elsewhere
you said you want, because you do not want to be obligated to declare ::moda
to have a default value for $::modb::param. I say again: $::moda::param *has
no value* -- neither in a conceptual sense nor in manifest evaluation sense
-- until class ::moda has been declared.
John
--
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/d34f00d8-79e8-43bb-b589-1c25c2b79128%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
