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.
