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/02ccf438-5196-481b-935d-b8971919e239%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
