The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #12789

Overwriting a class that's using a definition fails

Added by Thomas Sturm over 2 years ago. Updated over 2 years ago.

Status:ClosedStart date:02/23/2012
Priority:HighDue date:
Assignee:Chris Price% Done:

0%

Category:class inheritance
Target version:-
Affected Puppet version:2.7.11 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Hello,

please apologize if this was reported elsewhere already…

We have class X that’s included in the default node. The class uses a defined type of the same class with ensure => present. We also have class Y that inherits X and sets this defined type ensure => absent. If we assign Y to a node via another class or via ENC, it does nothing. The defined type is still ensure => present. However, if we assign class Y via a node definition, it works, the define is ensure => absent.

Overwriting native puppet types always works, but as soon as you are overwriting a definition, the overwrite does just nothing.

If this is supposed to work, I think we hit a bug here…

Best regards, Thomas

test1.pp (352 Bytes) Chris Price, 03/26/2012 06:10 pm

test2.pp (383 Bytes) Chris Price, 03/26/2012 06:10 pm

test3.pp (576 Bytes) Chris Price, 03/28/2012 04:38 pm

test4.pp (633 Bytes) Chris Price, 03/28/2012 04:38 pm

History

#1 Updated by Peter Meier over 2 years ago

It would be a lot easier to verify your bug with sample code.

And can you still verify it with the latest version?

#2 Updated by Chris Price over 2 years ago

  • Status changed from Unreviewed to Needs More Information
  • Assignee set to Thomas Sturm

Hi Thomas,

Can you possibly throw together a very simple manifest file to demonstrate this behavior? We’ll be happy to take a deeper look at it then.

Thanks!

#3 Updated by Thomas Sturm over 2 years ago

Hi Chris,

thanks for taking care.

Here is a simple test, this is the base class with a define:

class test {

    file_definition {
        "/root/puppet-test":
            ensure  => present,
            content => 'Test successful';
    }

}
define test::file_definition(
    $ensure,
    $content = ''
) {

    file {
        "$name":
            content => $content,
            ensure  => $ensure;
    }

}

This is the class that overwrites the defined type ‘file_definition’:

class test::test_disabled inherits test {

    File_definition["/root/puppet-test"] {
        ensure => absent
    }

}

This does not work when test::test_disabled is assigned as include in another class or via ENC, but it works when assigned in the node manifest directly.

#4 Updated by Chris Price over 2 years ago

  • Status changed from Needs More Information to Investigating
  • Assignee changed from Thomas Sturm to Chris Price

Thanks Thomas, I will investigate further as soon as I get a chance.

#5 Updated by Chris Price over 2 years ago

Sorry Thomas, got side tracked for a while… resuming investigation on this now.

#6 Updated by Chris Price over 2 years ago

  • File test1.pp added
  • File test2.pp added
  • Status changed from Investigating to Needs More Information
  • Assignee changed from Chris Price to Thomas Sturm

Hi Thomas,

I’m unable to reproduce this so far. I’ve attached 2 simple manifests that I’m running with simply “puppet apply”. If I’m understanding your description correctly, the first one should match up with your expected behavior, and the second one (test2.pp) should trigger the error case that you’ve described (because it indirectly includes the overridden resource via the intermediate class “foo”.) However, they both appear to respect the overridden parameter when I run them.

Perhaps you can take a peek at them and see if you can tell what is different about what I’m doing here as compared to what’s happening in your environment?

Thanks!

#7 Updated by Thomas Sturm over 2 years ago

  • Assignee changed from Thomas Sturm to Chris Price
  • Affected Puppet version changed from 2.7.6 to 2.7.11

Hi Chris,

thanks for your update. Your test2.pp works as expected, however it’s a different story when running this with a master and an indirect include via an intermediate class or ENC. I have no idea what I could do to prove that to you or to give more information or what could cause this different behaviour. Please advise :) We upgraded to 2.7.11 recently, but still suffer from this bug.

Thomas

#8 Updated by Thomas Sturm over 2 years ago

Hey again,

my code from update #3 also works when run with “puppet apply”. But it does not when run with puppet agent…

#9 Updated by Chris Price over 2 years ago

  • Status changed from Needs More Information to Investigating

Great, thanks for the info—my goal for now is only to determine the bare minimum repro scenario. As soon as I get a chance I will attempt to repro w/the notify manifests via master/agent rather than apply, and we can go from there.

Your observations from your own environment are definitely helpful, so thanks for the updates to the ticket and please continue to do so if you find any new information.

#10 Updated by Chris Price over 2 years ago

  • File test3.pp added
  • File test4.pp added
  • Status changed from Investigating to Needs More Information
  • Assignee changed from Chris Price to Thomas Sturm

So… my test1.pp and test2.pp manifests seem to behave the same way via master/agent as they do via apply.

My next guess was that maybe this is something specific to either the ‘file’ resource type, or the ‘ensure’ parameter, or both… so I created test3.pp and test4.pp, which are based off of your code above.

Based on your description I’d expect:

  1. test3.pp does not create the file via ‘apply’
  2. test3.pp does not create the file via master/agent
  3. test4.pp does not create the file via ‘apply’
  4. test4.pp DOES create the file via master/agent

However, in all 4 permutations, I am not seeing the file get created. Any ideas what I’m doing differently from you?

#11 Updated by Thomas Sturm over 2 years ago

  • Assignee changed from Thomas Sturm to Chris Price

Now I’m rather confused. I can reproduce your results. I even can’t reproduce my own tests any more. However, our module which caused me to open this bug initially, still shows the problem. I think I’ll need to have a further look at this, feel free to close this bug in the meantime.

#12 Updated by Chris Price over 2 years ago

  • Status changed from Needs More Information to Closed

OK, thanks. I’ll close it for housekeeping purposes, because your new ticket is likely to receive more immediate attention than if we just left this one open indefinitely. However, it would probably be worth linking your new ticket to this one when you create it, so that we have the history available.

Thanks!

Also available in: Atom PDF