Ok, I see.
Thanks for all this discussion!
> No, you *never* need to use parameterized classes.
> If you are determined to avoid resource-like class declarations,
> then you can replace each parameterized class in your manifest set with a
non-parameterized version that obtains its data via direct hiera() calls.
you mean replacing:
class tomcat (
port = hiera('tomcat_port', 7070)
ssl_port = hiera('tomcat_port', 7071)
) {
notice $port
notice $ssl_port
}
by:
class tomcat {
$port = hiera('tomcat_port', 7070)
$ssl_port = hiera('tomcat_port', 7071)
notice $port
notice $ssl_port
}
?
for a java/scala software developer like me, this does not look a good,
because it makes it more difficult to unit test.
maybe with puppet it is easy to build and pass different hiera data for
unit testing?
> Hiera's YAML back end is not the ultimate solution, but the Hiera
*framework* can be.
> You can plug in pretty much any kind of data lookup or computation.
Ok. I didn't know about this neither. I'll take a look.
so, one specific example,
someone (not me) implemented a class tomcat with parameters port and
ssl_port.
I want to use that class,
and I want that the ssl_port is always port + 1 (I don't want this to be
configurable in hiera)
so, in my hiera data, I will specify port, and then I have my class:
class application ($port) {
class {tomcat:
port => $port
ssl_port => $port+1
}
class {nginx:
...
}
# configuration files...
}
how would you do this without using resource-like class declaration?
> Or you can make exactly one class responsible for performing any needed
computations and declaring the
> class for which you want to use a resource-like declaration, and any node
or other class must declare the
> wrapper class instead (using 'include' or one of its brethren).
I see. similar to the example42 params pattern. you mean something like:
class parameters {
$port = hiera("port")
$ssl_port = $port + 1
}
class tomcat {
include parameters
notice $parameters::port
notice $parameters::ssl_port
}
> I'm sorry that that is such a consternation for you.
haha, it's not that I am not consternated, but you know,
I come from an object-oriented and function programming paradigm,
and unlearning is twice as hard as learning. ;)
Regards,
David
On Monday, April 14, 2014 4:43:19 PM UTC+2, jcbollinger wrote:
>
>
>
> On Friday, April 11, 2014 10:10:37 PM UTC-5, David Portabella wrote:
>>
>> I didn't know about this *evaluation-order dependency.*
>> Why does this "evaluation-order dependency" exists in puppet?
>>
>
>
> Do you mean this particular one, or evaluation-order dependencies in
> general?
>
> Anyway, I started to write a detailed response to this, but it was turning
> into a novel. The bottom line is this: it would have been extremely
> difficult to design or implement Puppet in a way that foreclosed the
> possibility of users writing evaluation-order dependent manifest sets. PL
> could have come closer than they did do, but that's water under the bridge.
>
>
>
>> Is it done in purpose, or it is a technical problem of the puppet
>> implementation?
>>
>
>
> Evaluation-order dependency is not a design feature, but neither is it
> really a bug as such. I would describe it as a characteristic of the
> problem space.
>
> I don't think PL understood the magnitude of the specific associated
> evaluation-order dependency problem when they first rolled out
> parameterized classes in v2.6.0, but they certainly knew that there was
> one. On the other hand, earlier versions of Puppet had different
> evaluation-order dependency issues surrounding classes. It is a very
> difficult challenge for Puppet to protect users from all possible unwanted
> results of manifest evaluation order, while still providing all the desired
> results of manifest evaluation.
>
>
>
>> Do you have an example where we would want to use this evaluation-order
>> dependency?
>>
>
>
> No. It is always best to avoid evaluation-order dependencies in your
> manifests.
>
>
>
>> Or could puppet completely remove this concept?
>>
>>
>
> PL could remove the language features and built-ins that yield the
> greatest exposure to evaluation-order problems (e.g. resource-like class
> declarations and the defined() function), but I don't think they can remove
> all possibility that the result of compiling a manifest set depends on the
> order in which classes or the declarations within are evaluated. They
> cannot fix the problematic features to be non-problematic, however, as
> evaluation-order dependency is an inherent consequence of their nature.
>
> As a practical matter, PL is unlikely to remove the problematic features
> any time in the foreseeable future because the disruption to its user base
> would be prohibitive. That is, despite their problems, many people do use
> and rely on features encumbered with evaluation-order dependency issues.
>
>
>
>> about the other part of your post, if I understand your post correctly,
>> you are saying:
>>
>> 1- avoid using parameterized classes
>>
>
>
> No. I once did say that, but the actual problem is with the resource-like
> class declaration syntax. Since Puppet 3.0, parameterized classes can be
> used without the resource-like syntax, and that's just fine.
>
>
>
>> 2- but yes, sometimes you need parameterized classes
>>
>
>
> No, you *never* need to use parameterized classes. If you are determined
> to avoid resource-like class declarations, then you can replace each
> parameterized class in your manifest set with a non-parameterized version
> that obtains its data via direct hiera() calls. But that's beside the
> point, because parameterized classes are not themselves the problem, and
> not what I was talking about.
>
> My comments were about the resource-like class declaration syntax. You
> don't ever *need* that, either, but under some circumstances it is both
> convenient and relatively safe. Specifically, within a module, you can use
> it -- if you're careful -- to declare internal classes of the module. Note
> well: those conditions do not protect you from evaluation-order dependency;
> they merely allow you to manage it, because you can know and control all
> the places where internal classes are (supposed to be) used. And that's
> why I say only "relatively" safe.
>
>
>
>> 3- but that's not a problem, because the class can take the parameter
>> values from hiera
>>
>
>
>>
>> well, 1 and 2 are in contradiction, isn't it?
>>
>
>
> Your interpretation presents a contradiction, but what I am trying to
> communicate to you does not contain one.
>
> But yes, PL and I both say that your classes should generally obtain
> non-default class parameter values via hiera, rather than via resource-like
> declarations.
>
>
>
>>
>> and about 3, hiera is not the ultimate solution for data store.
>> what if you need to compute the parameter values programmatically?
>>
>
>
> Hiera's YAML back end is not the ultimate solution, but the Hiera
> *framework* can be. You can plug in pretty much any kind of data lookup
> or computation.
>
> Alternatively, you can put your computation inside the class, and feed it
> the input values as parameters. Or you can make exactly one class
> responsible for performing any needed computations and declaring the class
> for which you want to use a resource-like declaration, and any node or
> other class must declare the wrapper class instead (using 'include' or one
> of its brethren).
>
> What neither you nor PL can do is render resource-like class declaration
> syntax devoid of evaluation-order implications. I'm sorry that that is
> such a consternation for you.
>
>
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/da95cb48-05dc-4e05-86f6-39a09b0547bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
