(PUP-3248) Fix PMT tests for directory environment

[johnduarte]

The beaker host['distmoduledir'] variable is not meaningful if the
host is using directory environments (e.g. 'production').

This commit updates the helper methods for validating that a module
is (or is not) installed on the host by iterating over the
modulepath if a specific modulepath is not provided.

The calls to these helper methods have been updated for the change
in parameter ordering in the helper methods.

[puppetcla]

CLA signed by all contributors.

[jpartlow]

I think this is probably better specified as a 'puppet config print modulepath --environment '; default could be 'production'. Otherwise we're just obtaining the modulepath for whatever environment happens to be associated with the agent section of puppet.conf, (which is likely to be the default, 'production', but it's a little vague).

[johnduarte]

@jpartlow the purpose of this helper is to obtain the modulepath segments as an array. It is not intended to obtain the the environment.

[jpartlow]

Right, but modulepath is a property of the environment. Really all I'm saying is that it's clearer to obtain settings from puppet by using the puppet config tool and specifying environment and section as needed. A puppet agent --configprint modulepath is the equivalent of saying puppet config print --section agent modulepath And moving forward, modulepath is deprecated in a puppet.conf section. Instead you really need to be asking puppet config print modulepath --environment <something>

[johnduarte]

@jpartlow thank you for the additional context. I have pushed an update incorporating your suggested change to puppet config print modulepath --environment #{environment}.

[jpartlow]

Why don't we want these running in the pe suite?

[johnduarte]

@jpartlow Running these in PE does 'bad things' to the puppet master. I haven't had a chance to do the root cause analysis as to why yet.

[jpartlow]

I suspect it's because the generate_base_legacy_and_directory_environments is being given the real master['puppetpath']. We should probably change this to point to a tmpdir, and then I think this will be insulated.

[jpartlow]

Also, let's rebase this to stable and we'll merge up from there; since there's still discussion of a Puppet 3.7.2 and the pe-puppet 3.4.x is targeted to the 3.7.x puppet stable atm.

[johnduarte]

@jpartlow this has already been rebased on stable. Cheers.

[jpartlow]

The PR's still targeting master though?

[johnduarte]

@jpartlow this is the error I get if the environmentpath is not amended with the given path in the setup method.

  * Install a module into a non default legacy environment

centos6-64-ma 14:33:40$  puppet module install pmtacceptance-nginx --config=/tmp/environmentpath.Dygiq5/puppet2.conf --environment=legacyenv  
/opt/puppet/lib/ruby/site_ruby/1.9.1/puppet/application.rb:365:in `run': Could not find a directory environment named 'legacyenv' anywhere in the path: /etc/puppetlabs/puppet/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound)
    from /opt/puppet/lib/ruby/site_ruby/1.9.1/puppet/util/command_line.rb:146:in `run'
    from /opt/puppet/lib/ruby/site_ruby/1.9.1/puppet/util/command_line.rb:92:in `execute'
    from /usr/local/bin/puppet:8:in `<main>'

[jpartlow]

Ah, ok, I think what is going on. We are inheriting the original puppet.conf settings (sourced from $settings::config), and they now have environmentpath set, so that legacyenv is being ignored. So we do need to set environmentpath in the generate_base_legacy_and_directory_environments() method, but we want to set it to an empty string to begin with (clear it, essentially).

[jpartlow]

So I think this just needs to change to:

"environmentpath", ""

(and we can get ride of the envpath variable lines above that)

[johnduarte]

This PR needs to be reopened against the puppet stable branch.