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 puppet-users+unsubscr...@googlegroups.com.
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.
