> I'm not at PuppetConf, unfortunately. In this case, all I did was a simple
> CentOS "service puppetmaster restart" as I have in the past.
>
> But, I wonder if the fact there are older versions still present might
> contribute to this -- though it shouldn't be reading code from those
> locations.
>
> I down-rev'd back to 2.7 and it's working fine. This just seemed like an
> installation bug to me.
Yes, I was able to reproduce a very similar issue. Here's the
situation I think you found yourself in:
Rubygems supports multiple installations of the same gem at different
versions. If you have puppet 2.7.19 installed as a gem, and then run
gem install puppet, then you'll have _both_ 2.7.19 and 3.0.0.
In 3.0.0 we've removed the "puppetmasterd" executable. The
puppetmasterd executable shim generated by rubygems still exists in
your PATH though, which is a problem.
The exception was caused because the shim doesn't specify the version
of the puppet codebase it should load, it just specifies version = ">=
0" which causes the 2.7.19 puppetmasterd executable to cross-load the
3.0.0 puppet ruby library.
This doesn't work.
The work-around I suggest is to switch to using the command "puppet
master" instead of "puppetmasterd" This should work with by 2.7.19
and 3.0.0 and will load the correct library:
$ gem list puppet
*** LOCAL GEMS ***
puppet (3.0.0, 2.7.19)
$ which puppet
/Users/jeff/.rbenv/versions/1.8.7-p358/gemsets/development/bin/puppet
$ puppet --version
3.0.0
Hope this helps,
-Jeff