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

Bug #13858

Custom types in environments require loading into master's libdir

Added by eric sorenson over 2 years ago. Updated over 1 year ago.

Status:ClosedStart date:04/08/2012
Priority:NormalDue date:
Assignee:Patrick Carlisle% Done:

0%

Category:modules
Target version:3.0.0
Affected Puppet version: Branch:https://github.com/pcarlisle/puppet/tree/ticket/master/13858-types-in-environments
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

An attempt to distill down the back-and-forth from #4409, as it applies to 2.7.x:

  • The master needs to load new types locally to validate parameters
  • In order to do so, the type rb files need to be available in the master’s $libdir, and only get there by being pluginsync'ed
  • Therefore, environments which have custom types in $modulepath directories that the master does not itself use (when running as a client), cannot be used.

Related issues

Related to Puppet - Bug #4409: puppetmasterd does not find custom types for environment Closed 07/30/2010
Related to Puppet - Feature #11900: Dynamic environment interpolation in puppet master config... Needs More Information 01/11/2012 05/01/2012
Related to Puppet - Bug #12173: Masters cannot reliably distinguish between multiple vers... Accepted 01/25/2012
Related to Puppet - Bug #18154: Master and agent should not share libdir Accepted
Related to Puppet - Bug #18187: Cached *root* environment isn't cleared when Puppet::Node... Rejected

History

#1 Updated by Anonymous over 2 years ago

  • Category set to modules
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Michael Stahnke

Eric, thanks for distilling that down. Very much appreciated.

Mike, I think this is a genuine and painful bug, but not one that we can look at before Telly ships the first release. Do you concur?

#2 Updated by Patrick Carlisle over 2 years ago

  • Status changed from Needs Decision to In Topic Branch Pending Review
  • Assignee changed from Michael Stahnke to Patrick Carlisle
  • Branch set to https://github.com/pcarlisle/puppet/tree/ticket/master/13858-types-in-environments

My local testing is pretty basic but this patch works for me: https://github.com/pcarlisle/puppet/commit/71fda58f327d680f6c55dbf15c8443014d264f66

I would love some validation on that if you are in a position to test, eric

It won’t fix the situation of getting you the right version all the time if you’re using different versions of a type in different environments, but that’s a separate issue (#12173)

#3 Updated by Patrick Carlisle over 2 years ago

It’s possible that it depends on being in the master branch, not 2.7.x.

#4 Updated by Anonymous over 2 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release
  • Target version set to 3.x

Thanks, this is merged. We believe this resolves the problem; if not, please let us know.

#5 Updated by Anonymous over 2 years ago

  • Target version changed from 3.x to 3.0.0

#7 Updated by Moses Mendoza almost 2 years ago

  • Status changed from Merged - Pending Release to Closed

released originally in 3.0.0rc1, and again with 3.0.0-rc4

#8 Updated by Ewoud Kohl van Wijngaarden almost 2 years ago

Any chance this could be backported to the 2.6 series? I’ve tested it with a local modification and it solves the issue, but it makes upgrading a pain.

#9 Updated by eric sorenson almost 2 years ago

Edwoud – 2.6 is on critical-security-fix-only support, there are no releases of 2.6 planned. If you got a backport working, you should probably roll your own local packages. Feel free to ping me via email (eric0@puppetlabs.com) if there are specific things that are preventing you from upgrading to newer releases, I’m interested to hear about that sort of thing.

#10 Updated by Pall Valmundsson almost 2 years ago

How about a backport to the 2.7 series? Is the 2.7 also in critical-security-fix-only support?

#11 Updated by Jeff McCune almost 2 years ago

Pall Valmundsson wrote:

How about a backport to the 2.7 series? Is the 2.7 also in critical-security-fix-only support?

We don’t have any plans to backport this to Puppet 2.7 either, there have been enough changes between 2.7 and 3.0 related to plugins and code loading that it would be quite an undertaking to support this fix across the two major versions.

Are there issues blocking you from upgrading to Puppet 3.0?

#12 Updated by Pall Valmundsson almost 2 years ago

Jeff McCune wrote:

Pall Valmundsson wrote:

How about a backport to the 2.7 series? Is the 2.7 also in critical-security-fix-only support?

We don’t have any plans to backport this to Puppet 2.7 either, there have been enough changes between 2.7 and 3.0 related to plugins and code loading that it would be quite an undertaking to support this fix across the two major versions.

Are there issues blocking you from upgrading to Puppet 3.0?

Our “issue” is mainly that we’re running RHEL/CentOS 5 clients. I thought I’d ask since the commit is a two-liner and according to this (https://github.com/puppetlabs/puppet/commit/96712efeb543928704fc9938e7429552d8ded039#commitcomment-2129720) the patch works for 2.7, but I’d rather not roll my own 2.7 packages.

#13 Updated by Dominic Cleal over 1 year ago

I’m just looking into some specs that started failing with 2.7.20 and after a bisect, recognised the code that was added as the same code that went into 3.x to fix #13858:

commit 8173a6e6c199426381f1f9fb8d0a71e0d0c12f2a

commit 8173a6e6c199426381f1f9fb8d0a71e0d0c12f2a
Author: Daniel Pittman <daniel@puppetlabs.com>
Date:   Mon Jul 16 23:40:31 2012 -0700

    Avoid object creation/destruction when possible.

    Object creation and destruction, even over a short time-frame, is expensive,
    so where we can avoid it we should.

[..]
diff --git a/lib/puppet/metatype/manager.rb b/lib/puppet/metatype/manager.rb
index 597a89f..dfcc74d 100644
--- a/lib/puppet/metatype/manager.rb
+++ b/lib/puppet/metatype/manager.rb
@@ -108,17 +108,24 @@ module Manager
[..]
+    # Try loading the type.
+    if typeloader.load(name, Puppet::Node::Environment.current)
+      Puppet.warning "Loaded puppet/type/#{name} but no class was created" unless @types.include? name
     end

I haven’t figured out yet whether my problem is my fault or Puppet’s, but thought it might be of interest. Perhaps this issue has inadvertently been fixed in 2.7.20?

Also available in: Atom PDF