(#7746) Fix bootstrap issues from #7717 fix.

So, turns out the fix in #7717 introduced a failure when starting the Puppet
master on some versions of Ruby.  Weird stuff.  I figured it out, eventually.

You see, the process of bootstrapping Puppet is ... complex.  This file, like
many of our early initialization files, has an incestuous relationship between
the order of files loaded, code executed at load time, and code executed in
other files at runtime.

When we construct this object we have not yet actually loaded the global
puppet object, so we can't use any methods in it.  That includes all the
logging stuff, which is used by the deprecation warning subsystem.

On the other hand, we can't just load the logging system, because that depends
on the top level Puppet module being bootstrapped.  It doesn't actually load
the stuff it uses, though, for hysterical raisins.

Finally, we can't actually just load the top level Puppet module.  This one is
precious: it turns out that some of the code loaded in the top level Puppet
module has a dependency on the run mode values.

Run mode is set correctly *only* when the application is loaded, and if it is
wrong when the top level code is brought in we end up with the wrong settings
scattered through some of the defaults.

Which means that we have a dependency cycle that runs:
1. The binary creates an instance of P::U::CL.
2. That identifies the application to load.
3. It does, then instantiates the application.
   4. That sets the run-mode.
   5. That then loads the top level Puppet module.
6. Finally, we get to where we can use the top level stuff

So, essentially, we see a dependency between runtime code in this file,
run-time code in the application, and load-time code in the top level module.

Which leads me to our current horrible hack: we stash away the message we
wanted to log about deprecation, then send it to our logging system once we
have done enough bootstrapping that it will, y'know, actually work.

I would have liked to fix this, but that is going to be a whole pile of work
digging through and decrufting all the global state from the local state, and
working out what depends on what else in the product.

Oh, and we use a global because we have *two* instances of a P::U::CL object
during the startup sequence.  I don't know why.

Reviewed-By: Nigel Kersten <nigel@puppetlabs.com>
Reviewed-By: Nick Lewis <nick@puppetlabs.com>
Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>

0 files changed, 0 insertions, 0 deletions