Issue #1707 has been updated by luke. Status changed from Needs design decision to Rejected
I'm concerned that this drastically increases the opportunity for cross-class dependencies in ways that are entirely a bad idea. Just having the semi-global class variables available seems a semi-bad idea, but necessitated by the lack of built-in class attributes with deeper semantics (which I hope to add at some point). Enabling these variables to be modified is, I think, a bit beyond the pale. I'd prefer a comprehensive solution to add class attributes; something akin to jerico's recommendations for consolidating definitions and classes, but simplified and with a focus on just adding attributes to classes. ---------------------------------------- Feature #1707: Mutably append to variables given an absolute scope http://projects.reductivelabs.com/issues/show/1707 Author: jgoldschrafe Status: Rejected Priority: Normal Assigned to: luke Category: language Target version: unplanned Complexity: Unknown Affected version: 0.24.6 Keywords: Puppet uses relative scope for simplicity. This is useful in making sure that modules don't inadvertently step on variables defined elsewhere, like those from Facter. However, now that arrays can be appended to in 0.24.6, there are times in which you might want to intentionally append to a variable in a mutable way. For example, you might have the following: <pre> class firewall::common { $open_ports = ['22'] } class nrpe { include firewall::common $firewall::common::open_ports += ['5666'] #blahblah } class apache2 { include firewall::common $firewall::common::open_ports += ['80', '443'] #blahblah } class firewall::iptables { if $operatingsystem == 'centos' { File { 'system-config-securitylevel': path => '/etc/sysconfig/system-config-securitylevel', source => template('firewall/iptables/blahblah'), replace => 'false', #blahblah } } } </pre> It's confusing being able to specify a scoped variable, but having that scope actually copied into the current scope instead of actually operating on the variable named. Intuitively, trying to append to $firewall::common::open_ports should actually modify that variable. Since there's no "pop" operation or anything potentially destructive involved, there's no non-deterministic behavior that could result. You should end up with the same items in the list every time. I'm not entirely sure how Puppet works internally, but I'd imagine that all conditionals are applied and all variables interpolated before any resource actions are actually performed. Having variables mutably appended to when provided with an explicit scope would provide the ability for all modules in an environment to input their own requirements to a list, which can then be templated out. This is applicable to lots of other modules as well, notably NRPE, which can have its config file configured differently depending on, say, whether the system in question is running rsyslog or sysklogd. And since there's no "pop" operation for arrays, I don't see a reason why the order of application would be important, so this doesn't run against the Puppet philosophy. There's a lot of ways of doing things that aren't possible in Puppet right now that something like this would enable. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
