Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Currently when there is an error of some sort installing errata, the UI remains in an "Installing..." state for some time (not sure it's forever - it seems to eventually timeout) without ever throwing an error. Errors from the backend are not being passed through to ui layer.
Steps to Reproduce:
I don't know exact steps to produce an error, but in this case, I am seeing the following error in the gofer log on the client:
2012-01-24 12:39:40,221 [ERROR][worker-0] __call__() @ dispatcher.py:488 - Values instance has no attribute 'repos'
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/gofer/rmi/dispatcher.py", line 485, in __call__
retval = method(*args, **keywords)
File "/usr/lib64/gofer/plugins/katelloplugin.py", line 139, in install
installed = p.install(names)
File "/usr/lib64/gofer/plugins/package.py", line 115, in install
yb.install(pattern=info)
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3338, in install
mypkgs = self.pkgSack.returnPackages(patterns=pats,
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 882, in <lambda>
pkgSack = property(fget=lambda self: self._getSacks(),
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 668, in _getSacks
self.repos.populateSack(which=repos)
File "/usr/lib/python2.6/site-packages/yum/repos.py", line 265, in populateSack
self.doSetup()
File "/usr/lib/python2.6/site-packages/yum/repos.py", line 72, in doSetup
self.ayum.plugins.run('prereposetup')
File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 184, in run
func(conduitcls(self, self.base, conf, **kwargs))
File "/usr/share/yum-plugins/rhnplugin.py", line 199, in prereposetup_hook
for opt, repoexp in opts.repos:
AttributeError: Values instance has no attribute 'repos'
2012-01-24 12:39:40,227 [INFO][worker-0] sendreply() @ rmi.py:158 - 9b33d4d2-f7b9-406e-a64a-eea9867d8878 processed in: 1.205 (seconds)
Actual results:
Error on client side, UI continues showing "Installing..." as if nothing happened.
Expected results:
* If an error is thrown (on either host or client side), the error should bubble up to gui, resulting in some sort of failure message in the errata screen and/or notification log. At very least, it shouldn't give false sense of everything being hunky-dory.
Additional info:
Actual error above, while maybe important, is not 100% relevant to the bug itself, which is the simple need to bubble errors up to UI.
There have been significant changes upstream (and downstream), since this bug was initially created. This includes changes such as:
- upgraded versions of pulp
- ui re-written using angularjs
- content host actions updated to use dynflow
With all of these changes, if an error does occur which causes the a failure of a content host action, the user should now have traceability of the error through dynflow.
For now, I am going to close this BZ. If the issue comes back we can either reopen this one or file a new one.
Description of problem: Currently when there is an error of some sort installing errata, the UI remains in an "Installing..." state for some time (not sure it's forever - it seems to eventually timeout) without ever throwing an error. Errors from the backend are not being passed through to ui layer. Steps to Reproduce: I don't know exact steps to produce an error, but in this case, I am seeing the following error in the gofer log on the client: 2012-01-24 12:39:40,221 [ERROR][worker-0] __call__() @ dispatcher.py:488 - Values instance has no attribute 'repos' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/gofer/rmi/dispatcher.py", line 485, in __call__ retval = method(*args, **keywords) File "/usr/lib64/gofer/plugins/katelloplugin.py", line 139, in install installed = p.install(names) File "/usr/lib64/gofer/plugins/package.py", line 115, in install yb.install(pattern=info) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3338, in install mypkgs = self.pkgSack.returnPackages(patterns=pats, File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 882, in <lambda> pkgSack = property(fget=lambda self: self._getSacks(), File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 668, in _getSacks self.repos.populateSack(which=repos) File "/usr/lib/python2.6/site-packages/yum/repos.py", line 265, in populateSack self.doSetup() File "/usr/lib/python2.6/site-packages/yum/repos.py", line 72, in doSetup self.ayum.plugins.run('prereposetup') File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 184, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/share/yum-plugins/rhnplugin.py", line 199, in prereposetup_hook for opt, repoexp in opts.repos: AttributeError: Values instance has no attribute 'repos' 2012-01-24 12:39:40,227 [INFO][worker-0] sendreply() @ rmi.py:158 - 9b33d4d2-f7b9-406e-a64a-eea9867d8878 processed in: 1.205 (seconds) Actual results: Error on client side, UI continues showing "Installing..." as if nothing happened. Expected results: * If an error is thrown (on either host or client side), the error should bubble up to gui, resulting in some sort of failure message in the errata screen and/or notification log. At very least, it shouldn't give false sense of everything being hunky-dory. Additional info: Actual error above, while maybe important, is not 100% relevant to the bug itself, which is the simple need to bubble errors up to UI.