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

Bug #12923

$environment doesn't work with import

Added by Nathan Campi about 2 years ago. Updated about 2 years ago.

Status:RejectedStart date:03/01/2012
Priority:HighDue date:
Assignee:Nigel Kersten% Done:

0%

Category:environments
Target version:-
Affected Puppet version: 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

Create a site.pp like this:

notify { 'environment_notify':
        message => "NOTICE: This system is being configured with the environment ${environment}."
}

import "environments/$environment/nodes/*.pp"

You’ll get your environment in the notification, but then you’ll get an error from the import like:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not parse for environment production: Syntax error at 'environments/' at /etc/puppet/manifests/site.pp:27 on node foobar

Puppet version 2.6.4 on client and server. It’s entirely appropriate, IMHO, for puppet to be able to interpolate the $environment var on an import line.

Thanks.

History

#1 Updated by James Turnbull about 2 years ago

  • Description updated (diff)

#2 Updated by James Turnbull about 2 years ago

  • Category set to environments
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Nigel Kersten

Nate – it’s pretty unlikely we’re going to fix this. We’re deprecating import entirely in favour of autoloading and controlling what is loaded using the modulepath. Indeed that’s the approach I’d recommend instead of doing anything with import.

But I’ve asked Nigel to review the ticket.

#3 Updated by Nigel Kersten about 2 years ago

  • Status changed from Needs Decision to Rejected

James has it right. Import isn’t an area we’re investing in, and there’s a reasonably simple workaround here.

Set the ‘manifest’ directive per-environment in puppet.conf, and then you can do relative imports based upon the environment.

As of the next release of Puppet import will be deprecated, and the most frictionless way to work is going to be to use modules with the autoloader (which occurs per-environment.

#4 Updated by Nigel Kersten about 2 years ago

See #12929 for the details around import deprecation, and the associated ticket for a directory per-environment where manifests are automatically parsed.

#5 Updated by eric sorenson about 2 years ago

I know it’s bad, deprecated, etc. But this seems even wronger than I’d expect:

[eric@leterel ~/puppet-test]$ more file1.pp 
if $hostname =~ /sfsfsfst/ {
    import "file2.pp"
}
notice "Hey done with 1"
[eric@leterel ~/puppet-test]$ cat file2.pp 
notice "Hey we're in 2"
[eric@leterel ~/puppet-test]$ puppet apply --confdir=/tmp ./file1.pp
notice: Scope(Class[main]): Hey we're in 2
notice: Scope(Class[main]): Hey done with 1
notice: Finished catalog run in 0.01 seconds

Is that known not to work?

Also available in: Atom PDF