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.
