Bug 985012

Summary: Prevent Error 500 due to IndividualClusterController.model being None
Product: Red Hat Enterprise Linux 6 Reporter: Jan Pokorný [poki] <jpokorny>
Component: luciAssignee: Jan Pokorný [poki] <jpokorny>
Status: CLOSED DUPLICATE QA Contact: Cluster QE <mspqa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4CC: cluster-maint, rsteiger
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 08:09:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Pokorný [poki] 2013-07-16 14:47:26 UTC
During testing luci vs. python-weberror in FIPS mode [bug 746118],
I've discovered that URLs like these:

  https://${HOST}:8084/cluster/${CLUSTERNAME}/failovers
  https://${HOST}:8084/cluster/${CLUSTERNAME}/fences
  https://${HOST}:8084/cluster/${CLUSTERNAME}/resources
  https://${HOST}:8084/cluster/${CLUSTERNAME}/services

lead to Error 500: We're sorry but we weren't able to process this request
(which involved Beaker middleware and the FIPS-related bug caused emitting
plain "Internal Server Error").


The tracebacks follow this pattern:

File '/usr/lib/python2.6/site-packages/pylons/wsgiapp.py',
line 125 in __call__
  response = self.dispatch(controller, environ, start_response)
File '/usr/lib/python2.6/site-packages/pylons/wsgiapp.py',
line 324 in dispatch
  return controller(environ, start_response)
File '/usr/lib64/python2.6/site-packages/luci/controllers/root.py',
line 53 in __call__
  return BaseController.__call__(self, environ, start_response)
File '/usr/lib64/python2.6/site-packages/luci/lib/base.py',
line 30 in __call__
  return TGController.__call__(self, environ, start_response)
File '/usr/lib/python2.6/site-packages/pylons/controllers/core.py',
line 221 in __call__
  response = self._dispatch_call()
File '/usr/lib/python2.6/site-packages/pylons/controllers/core.py',
line 172 in _dispatch_call
  response = self._inspect_call(func)
File '/usr/lib/python2.6/site-packages/pylons/controllers/core.py',
line 107 in _inspect_call
  result = self._perform_call(func, args)
File '/usr/lib/python2.6/site-packages/tg/controllers.py',
line 857 in _perform_call
  self, controller, params, remainder=remainder)
File '/usr/lib/python2.6/site-packages/tg/controllers.py',
line 172 in _perform_call
  output = controller(*remainder, **dict(params))

-- ONE OF --

# failovers
File '/usr/lib64/python2.6/site-packages/luci/controllers/cluster.py',
line 816 in failovers
  if not self.model.getFailoverDomainByName(failovername):
AttributeError: 'NoneType' object has no attribute 'getFailoverDomainByName'

# fences
File '/usr/lib64/python2.6/site-packages/luci/controllers/cluster.py',
line 936 in fences
  if not self.model.getFenceDeviceByName(fencename):
AttributeError: 'NoneType' object has no attribute 'getFenceDeviceByName'

# resources
File '/usr/lib64/python2.6/site-packages/luci/controllers/cluster.py',
line 516 in resources
  self.model.getResourceByName(resourcename)
AttributeError: 'NoneType' object has no attribute 'getResourceByName'

# services
File '/usr/lib64/python2.6/site-packages/luci/controllers/cluster.py',
line 644 in services
  if not self.model.getService(servicename):
AttributeError: 'NoneType' object has no attribute 'getService'

-- === ---


This should be captured in the earlier processing and the error note
should be emitted accordingly.

Sidenote: what are the states leading to model attribute being None?
I reproduced the issue with node-less cluster, unfortunately don't
recall if this is artificial degenerate case or something one can
set up deliberately.

Comment 2 Jan Pokorný [poki] 2013-07-16 20:25:22 UTC
re [comment 0]:

> Sidenote: what are the states leading to model attribute being None?
> I reproduced the issue with node-less cluster, unfortunately don't
> recall if this is artificial degenerate case or something one can
> set up deliberately.

The situation was
- add/create cluster with 1+ node(s)
- stop ricci on all of these
  - this should cause no node to be listed in the nodes overview
- try to display cluster's fences, etc. as per URLs above

Apparently, luci should be robust enough to deal with such situation.
Perhaps the whole luci DB vs. reality + no authoritative data logic
scenario should be reconsidered to better fit expectations.

Comment 4 Radek Steiger 2013-08-01 08:09:09 UTC

*** This bug has been marked as a duplicate of bug 878149 ***