Jira (PUP-1417) puppet parser not order independent

[Paul Pham (JIRA)]

Title: Message Title

Paul Pham commented on an issue   Re: puppet parser not order independent We are attempting to follow Craig Dunn's roles and profiles approach to module building. http://www.craigdunn.org/2012/05/239/ We are also trying to develop something we're referring to as a "co-op" model, where modules can be loosely coupled in order to provide enhanced functionality but without creating hard dependencies between modules. The following isn't a complete code sample, but should hopefully give an idea as to what we're trying to accomplish: profile_baseos/manifests/init.pp class profile_baseos { ... class {"::ntp": } class {"::sensu::client": } #Installs and configures a sensu client class {"::monit": } #Installs and configures monit ... } monit/manifiests/init.pp # One of the resources inside the monit module defines a 'shared config' directory. # Effectively this ends up being /etc/monit.d/ ... file { $include_dir: ensure => 'directory', require => Package['monit'], } ... sensu/manifiests/client.pp ... # The goal here is to drop a monit config that is specifically for monitoring the sensu-client # the config should be created as /etc/monit.d/sensu-client.monit.cfg # However, since the monit module is responsible for creating that 'include_dir' path, we want to refer # directly to that variable, since the monit module 'owns' that resource and may decide to move that # path elsewhere. # We can only safely refer to $monit::include_dir from within the sensu::client class if # class monit has been declared in this puppet run. if defined(Class["monit"]){ validate_absolute_path($monit::include_dir) file { 'sensu-client.monit.cfg': ensure => file, path => "${monit::include_dir}/sensu-client.monit.cfg", content => template('sensu/sensu-client.monit.cfg.erb'), require => Package['monit'], notify => Service['monit'], #refresh monit after adding this file } } So let's assume I execute this code by doing a `puppet apply -e "include profile_baseos"`. The problem is, since the `defined` function is parse order dependent, the code shown above inside the sensu::client class doesn't get evaluated (and the sensu-client.monit.cfg does not get dropped into the appropriate directory). This caught us totally off guard, since puppet execution/evaluation is so vehemently random. The puppet run doesn't fail, but it took us a while to figure out why the code inside this block wasn't being executed since the classes were clearly defined in profile_baseos. The workaround is to move that code around in profile_baseos so that the lowest common denominator classes are "declared first" (despite the fact that the resources are still evaluated in random order). In concrete terms it means I needed to declare class monit before class sensu::client inside profile_baseos, even though that changes nothing with regard to evaluation order. I have to say, the OCD in me wants to implode. This is the kind of stuff that makes me long for chef... If you want puppet to be order independent and declarative, then do it! Otherwise it feels like you're making the evaluation order random just to mess with us.You're basically requiring that I declare these classes "in order" (due to parse order dependence) without giving me any way to require that they are evaluated "in order" unless I create massive dependencies between modules. For example, you might ask why I don't go ahead and 'include monit' at the top of my sensu::client class. That would couple these two modules together and I would never be able to declare sensu::client with also declaring the monit module, which is something we're explicitly trying to avoid. Class containment will help, but only if it is my intent to order resources evaluation. In this case, I'm being forced to deal with puppet parser's order dependence, even though the classes in question do not have evaluation order dependence. I'd also argue that if the `defined` function (and by extension the puppet parser) must be order dependent, then you need to change your function names. `defined_in_code_parsed_before_this_point_but_not_necessarily_evaluated_before_this_point` would be more accurate. /snark Apologies for the rant, but when I found this 5 year old issue that hadn't been addressed in over a year (despite the acknowledgement that this is a bug in the language) I got a little irritated. Add Comment   Puppet / PUP-1417 puppet parser not order independent The puppet parser has number of issues regarding order-of evaluation: * It does not always ensure that included classes are evaluated before qualified variables referring to them are evaluated. ([[LanguageTutorial#qualified-variables]]) * It may evaluate classes before the scope in which they are defined is evaluated. * the defined() function is "unf... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.