Red Hat Bugzilla – Bug 616519
puppet warnings about metaclass deprecation
Last modified: 2011-09-27 19:02:05 EDT
Description of problem:
Puppet 0.25.5 which was pushed to Fedora a little while back has the following problem
With the following fix:
I have uploaded a patch encapsulating the fix in a manner which can be applied to the spec file to my site:
Version-Release number of selected component (if applicable):
I discovered this when creating and booting virtual appliance via appliance-creator resulting in many "metaclass deprecated" warnings in the appliances boot log.
Steps to Reproduce:
You can download the kickstart I'm using here
Note, comment out the bit about the 'polisher-maintenance' repository as well as the "rubygem(rails) = 2.3.8" package below since neither of those will be accessible locally.
I'm guessing that this will occur in any appliance thought since puppet is required by the appliance tools
1. sudo appliance-creator -n fedora-ruby-187 -c maintenance.ks --cache /var/tmp/act
2. sudo virt-image fedora-ruby-187/fedora-ruby-187.xml
3. Open virt-manager or virt-viewer and view the vm's boot log
Many warnings stating:
"DEPRECATION WARNING: metaclass is deprecated and will be removed from Rails 2.3"
Followed by the puppet service reporting that it failed to start / install the base appliance
No warning and successful appliance installation
I've confirmed locally that applying the patch results in the warnings going away (though the startup log is still indicating that puppet failed to install the base appliance, though this may be a separate issue).
Note this may only be occurring against Rails 2.3.8 which I'm working toward getting ready for Fedora. (I haven't confirmed this either way)
Regardless, it is an issue that will need to be resolved when the updated Rails version is pushed (the latest puppet releases, off the 2.6.0 branch, has this fix included but it seems some of the appliance-creator's puppet scripts are incompatible with puppet 2.6.0 as indicated by failures in appliance boot log)
It doesn't look like this affects Fedora as shipped with rails 2.3.5. At least, no other reports have come in and I don't see it myself. The fix is in the 0.25.x branch upstream, as well as in 2.6.x. If we don't move to 2.6.x soon, we may well see a 0.25.6 release from upstream. Failing either of those, we can pull in the upstream patch for a 0.25.5 update if/when rails is updated.
I'd be interested if you can keep us apprised of the progress of rails 2.3.8 in Fedora so we can be sure to have a puppet update in place at or before that time to ensure things work well for users.
I'd also be interested in knowing what issues appliance creator is having with 2.6.0 and if the same manifests worked without issue in 0.25.5. Such regressions would be considered bugs upstream I believe. At the least, they may affect our decision to update to 2.6.x or stick with 0.25.x.
I've got a testing repository for puppet 2.6.0 at:
(In reply to comment #2)
> It doesn't look like this affects Fedora as shipped with rails 2.3.5. At
> least, no other reports have come in and I don't see it myself. The fix is in
> the 0.25.x branch upstream, as well as in 2.6.x. If we don't move to 2.6.x
> soon, we may well see a 0.25.6 release from upstream. Failing either of those,
> we can pull in the upstream patch for a 0.25.5 update if/when rails is updated.
I've updated the puppet rpm for the time being (for testing / local purposes), and uploaded the spec / srpm here:
> I'd be interested if you can keep us apprised of the progress of rails 2.3.8 in
> Fedora so we can be sure to have a puppet update in place at or before that
> time to ensure things work well for users.
The rails 2.3.8 rpms are pretty close to completion. I uploaded the latest releases to my blog here
I've also taken over ownership of the packages in Fedora. I think the concensus on ruby-sig is to push them into F14-updates.
One thing that I also wanted to accomplish sooner than later with this, is to remove the ancient ruby-activerecord and ruby-activesupport packages (which have been long replaced with rubygem-ar and -as).
AFAIK one of the only things holding us back from doing so is making sure puppet is no longer dependent on those. Apparently there wasn't a build dependency per-se, rather puppet checked to see if they were present in certain circumstances. I was wondering if you could comment on whether or not this is still the case and if puppet depends on either of those.
> I'd also be interested in knowing what issues appliance creator is having with
> 2.6.0 and if the same manifests worked without issue in 0.25.5. Such
> regressions would be considered bugs upstream I believe. At the least, they
> may affect our decision to update to 2.6.x or stick with 0.25.x.
Unfortunately I don't have any cycles to come up with a reproducible sequence of steps to illustrate this, but I ran into this problem when simply trying to startup a base_appliance vm created with appliance-creator which pulled the 2.6.0 puppet rpms.
At some point puppet complained about one of the commands ace was trying to execute (I believe it was in the firewall module, but am not sure) and failed to finish the installation. Sorry I don't currently have any more details.
Hey just a quick update. I pushed Rails 2.3.8 to rawhide and am looking for thoughts on pushing the rpms to F14 updates (see ruby-sig).
I also retired the ruby-activerecord and ruby-activesupport rpms.
puppet-2.6.6-1.fc14 has been submitted as an update for Fedora 14.
puppet-2.6.6-1.el5 has been submitted as an update for Fedora EPEL 5.
puppet-2.6.6-1.fc15 has been submitted as an update for Fedora 15.
puppet-2.6.6-1.fc13 has been submitted as an update for Fedora 13.
puppet-2.6.6-1.el6 has been submitted as an update for Fedora EPEL 6.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
This has been resolved in the 2.6.x version of puppet which has been pushed to Fedora
2.6.x is still in -testing. The updates system would have automatically closed this when it went to stable. :)
Ah my bad, had already pulled the updated puppet in, tested it, and make sure this bug was resolved.
Closed as I received a needinfo? from the Bug Zapper as this was filed against Fedora 13 which is approaching its end of life.
If the updated version of puppet does not make it into stable, we can reopen and address this from there.
puppet-2.6.6-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
puppet-2.6.6-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
puppet-2.6.6-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
puppet-2.6.6-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.