Question about Puppet 3.7 -- where in the code does it read directory environment contents (modules, manifests, and environment.conf)?

[Victor Danilchenko]

Hi all,

Quick background: I am migrating my company's Puppetmaster installation from 3.4 to 3.7 (on Centos 6, using PuppetLabs RPM repo), and simultaneously migrating to directory environments; or, more accurately, trying to. The problem is that my Puppet installation recognizes that environments exist (specifying non-existent environment throws an error) but ignores manifests, modules, and environment.conf within it ('puppet module list' returns 'no modules found', it doesn't find my node manifests, and overriding modulepath in environment.conf has no effect). Gory details here.

So, trying to debug this myself, I decided to do some code spelunking, attempting to find why Puppet fails to read my environments/production/modules directory. In doing so, I quickly realized that the puppet code follows a pretty fancy execution path, and I really have no idea how to find where something isn't happening.

Therefore, I am asking for help. Can anyone tell me where in the code Puppet 3.7.2 is supposed to read the environment contents? I am pretty sure that once I know where to look for failure, which module/class/method, I should be able to determine exactly why it fails.

Thanks in advance!

[Joshua Partlow]

On Tue, Oct 28, 2014 at 1:01 PM, Victor Danilchenko <epist...@gmail.com> wrote:

Hi all,

Quick background: I am migrating my company's Puppetmaster installation from 3.4 to 3.7 (on Centos 6, using PuppetLabs RPM repo), and simultaneously migrating to directory environments; or, more accurately, trying to. The problem is that my Puppet installation recognizes that environments exist (specifying non-existent environment throws an error) but ignores manifests, modules, and environment.conf within it ('puppet module list' returns 'no modules found', it doesn't find my node manifests, and overriding modulepath in environment.conf has no effect). Gory details here.

Hi Victor,

I think you may be running afoul of PUP-3500.  There are a handful of settings, certname among them, which are causing an early version of the Puppet settings values to be cached, and leaving you with incorrect modulepath/manifest in your configured environment (production by default). 

Try commenting out 'certname' and see if this resolves the problem.  If so, the fix is in stable, and should go out with 3.7.3, or your can try a patch from this commit: https://github.com/puppetlabs/puppet/commit/e134843b44d6d2a9ba3d661f34e5c971b6600120

hope this helps,

Josh

So, trying to debug this myself, I decided to do some code spelunking, attempting to find why Puppet fails to read my environments/production/modules directory. In doing so, I quickly realized that the puppet code follows a pretty fancy execution path, and I really have no idea how to find where something isn't happening.

Therefore, I am asking for help. Can anyone tell me where in the code Puppet 3.7.2 is supposed to read the environment contents? I am pretty sure that once I know where to look for failure, which module/class/method, I should be able to determine exactly why it fails.

Thanks in advance!

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/a1df64bf-68af-4153-93a9-54ed7a2aa4b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Josh Partlow

jpar...@puppetlabs.com

Developer, Puppet Labs

[Victor Danilchenko]

Yup, I just figured out (by randomly twiddling knobs) that certname is the culprit.

We try to run with repo-only code, so I am reluctant to patch package binaries. When do you guys expect to have 3.7.3 out? And what terrible thing will happen if I simply keep 'certname' disabled?

Thanks!

[Joshua Partlow]

On Tue, Oct 28, 2014 at 2:05 PM, Victor Danilchenko <epist...@gmail.com> wrote:

Yup, I just figured out (by randomly twiddling knobs) that certname is the culprit.

We try to run with repo-only code, so I am reluctant to patch package binaries. When do you guys expect to have 3.7.3 out?

Soon? :)  There is not currently that much waiting for 3.7.3, but we don't have a date set yet.

 

And what terrible thing will happen if I simply keep 'certname' disabled?

The master will end up using a default certname, which I believe will consist of the 'hostname.domain' returned by facter.

 

Thanks!

On Tuesday, October 28, 2014 4:01:05 PM UTC-4, Victor Danilchenko wrote:

Hi all,

Quick background: I am migrating my company's Puppetmaster installation from 3.4 to 3.7 (on Centos 6, using PuppetLabs RPM repo), and simultaneously migrating to directory environments; or, more accurately, trying to. The problem is that my Puppet installation recognizes that environments exist (specifying non-existent environment throws an error) but ignores manifests, modules, and environment.conf within it ('puppet module list' returns 'no modules found', it doesn't find my node manifests, and overriding modulepath in environment.conf has no effect). Gory details here.

So, trying to debug this myself, I decided to do some code spelunking, attempting to find why Puppet fails to read my environments/production/modules directory. In doing so, I quickly realized that the puppet code follows a pretty fancy execution path, and I really have no idea how to find where something isn't happening.

Therefore, I am asking for help. Can anyone tell me where in the code Puppet 3.7.2 is supposed to read the environment contents? I am pretty sure that once I know where to look for failure, which module/class/method, I should be able to determine exactly why it fails.

Thanks in advance!

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/08363354-1277-429d-b24f-c5d919366056%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 10/28/2014 10:52 PM, Joshua Partlow wrote:

And what terrible thing will happen if I simply keep 'certname' disabled?

The master will end up using a default certname, which I believe will consist of the 'hostname.domain' returned by facter.

Yeah. From experience, it relies on the fqdn fact, which on Linux is pretty much the output of `dnsdomainname -f`.

Cheers,
Felix

[Victor Danilchenko]

Thanks guys, this is really helpful -- sounds like turning off 'certname' is a perfectly acceptable workaround, which lets me move on with the migration.