Ah, OK. I'm not sure if I'm using default parameters in this way with my defines. I'm not currently using parameterized classes so that's a non-issue for me ATM.
I am concerned about the break in semantic consistency however. As we've seen on the users list numerous times one of the challenges of being a new Puppet user is the difficulty of tracking the delta between what's acceptable in a class, a resource, and a define. This seems like it would widen that semantic gap further. On Tue, Sep 18, 2012 at 1:19 PM, Erik Dalén <[email protected]> wrote: > That is not affected, only undef passed in parameters to classes and defines. > > On 17 September 2012 21:58, Aaron Grewell <[email protected]> wrote: >> Well, we have a situation where an existing web server needs to be >> managed but the application support folks have done something special. >> So we have the "please don't break the existing config" class, >> overriding our usual "you get the standard config so put your >> specialness in httpd.conf.d" class. >> >> class http::linux::custom inherits http::linux::install { >> File [ "/etc/httpd/conf/httpd.conf" ]{ >> ensure => undef, >> mode => undef, >> source => undef, >> owner => undef, >> group => undef, >> notify => undef, >> require => undef, >> } >> } >> >> >> On Mon, Sep 17, 2012 at 12:01 PM, Daniel Pittman <[email protected]> >> wrote: >>> On Mon, Sep 17, 2012 at 11:58 AM, Eric Sorenson >>> <[email protected]> wrote: >>>> Aaron -- could you distill this down to a code sample? Unless I'm >>>> misunderstanding, it sounds like your case is slightly different to the >>>> ones >>>> I posted. Thanks. >>> >>> I recognise the case; this is a different use and, as far as I >>> understand, shouldn't be changed. >>> >>> (It is also consistent with how the *new* behaviour of undef vs >>> parameter defaults works. :) >>> >>>> On Friday, September 14, 2012 3:29:05 PM UTC-7, Aaron Grewell wrote: >>>>> >>>>> I'm using the current behavior in inherited classes to unset parameters >>>>> set by the parent class. If that no longer works it will definitely >>>>> impact >>>>> my code. >>>>> >>>>> On Sep 14, 2012 11:31 AM, "Eric Sorenson" <[email protected]> >>>>> wrote: >>>>>> >>>>>> Hi, there's an issue that came up recently in the 3.0RCs -- Big thanks to >>>>>> Erik Dalén for reporting it in #16221 -- that involves a behaviour >>>>>> change to >>>>>> part of the DSL. In a nutshell, this code: >>>>>> >>>>>> define foobar ($param='Hello world') { >>>>>> notice($param) >>>>>> } >>>>>> foobar { 'test': param => undef } >>>>>> >>>>>> in 2.7, causes 'Hello world' in the notice. In 3.x, it's nothing. As I >>>>>> said in the bug, this seems more correct to me -- I've overriden the >>>>>> default >>>>>> with an explicit 'undef', taking off the default. The same thing goes for >>>>>> invoking parameterised classes with undef arguments, which is perhaps >>>>>> more >>>>>> ambiguous (example from matthaus): >>>>>> >>>>>> class toplevel ( >>>>>> $maybe = false, >>>>>> $optional = undef ) { >>>>>> if ($maybe) { >>>>>> class { toplevel::secondlevel: optional => undef } >>>>>> } >>>>>> } >>>>>> >>>>>> In order to make use of the default for the `optional` parameter in >>>>>> toplevel::secondlevel, you'd now need to either test in `toplevel` >>>>>> whether >>>>>> `$optional` was passed into it, or have toplevel::secondlevel use an >>>>>> `$optional_real` value inside it, similar to what's commonly done to >>>>>> append >>>>>> to defaults that are array values. >>>>>> >>>>>> The closest thing to documentation around this suggests the new behaviour >>>>>> is what's intended >>>>>> <http://docs.puppetlabs.com/puppet/2.7/reference/lang_classes.html#overriding-resource-attributes>: >>>>>> >>>>>> You can remove an attribute’s previous value without setting a new >>>>>> one by overriding it with the special value undef: >>>>>> >>>>>> class base::freebsd inherits base::unix { >>>>>> File['/etc/passwd'] { >>>>>> group => undef, >>>>>> } >>>>>> } >>>>>> >>>>>> So, I'm trying to determine whether this is a widespread pattern or an >>>>>> edge-case. Do you expect 'param=>undef' to be the same as not specifying >>>>>> param at all, or for the receiver to "see" the undef? >>>>>> >>>>>> Eric Sorenson - [email protected] >>>>>> >>>>>> PuppetConf'12 - 27-28 Sep in SF - http://bit.ly/pcsig12 >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups >>>>>> "Puppet Developers" 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-dev?hl=en. >>>>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Puppet Users" group. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msg/puppet-users/-/KtqHUAhcelcJ. >>>> 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-users?hl=en. >>> >>> >>> >>> -- >>> Daniel Pittman >>> ⎋ Puppet Labs Developer – http://puppetlabs.com >>> ♲ Made with 100 percent post-consumer electrons >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Developers" 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-dev?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" 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-dev?hl=en. >> > > > > -- > Erik Dalén > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" 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-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
