500 error during TPAAS for some charms

Bug #1168093 reported by Marco Ceppi
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

I can't seem to find anything in common with the requests at the moment, wanted to start this bug to track the issue.

INFO:werkzeug: - - [26/Apr/2013 10:38:23] "GET /plan/precise/tomcat7 HTTP/1.1" 500 -
ERROR:werkzeug:Error on request:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/Werkzeug-0.8.3-py2.7.egg/werkzeug/serving.py", line 159, in run_wsgi
  File "/usr/local/lib/python2.7/dist-packages/Werkzeug-0.8.3-py2.7.egg/werkzeug/serving.py", line 146, in execute
    application_iter = app(environ, start_response)
  File "/home/marco/Projects/charmrunner/charmrunner/server.py", line 100, in __call__
    return self.wsgi_app(environ, start_response)
  File "/home/marco/Projects/charmrunner/charmrunner/server.py", line 96, in wsgi_app
    response = self.dispatch_request(request)
  File "/home/marco/Projects/charmrunner/charmrunner/server.py", line 86, in dispatch_request
    result = getattr(self, "on_%s" % endpoint)(request, **values)
  File "/home/marco/Projects/charmrunner/charmrunner/server.py", line 113, in on_plan
    plan = next(plan_iter)

This has been checked against upstream lp:charmrunner, though the branch producing these errors is lp:~marcoceppi/charmrunner/add-server

Related branches

Revision history for this message
Marco Ceppi (marcoceppi) wrote :

I was able to resolve the majority of the 500 errors by changing the way <revno> was picked up from the URL. Instead of using the <charm>-<revno> format I switched my branch to use <charm>:<revno>. Subordinates also throw a 500 error but this is probably to be expected given their nature. A few other charms that don't meet those two criteria which are still producing 500 errors are listed below:


I'm not worried about the OpenStack charms, as graph testing those are burdensome for charmtester, but the rest should be able to generate plans. I'll dig deeper to see if I can find a common reason why these fail to build test plans.

description: updated
Revision history for this message
Marco Ceppi (marcoceppi) wrote :

It appears the 500 error is generated when plan fails to find a matching interface under the "requires" section of charm. Offending interfaces per charm:

glance: requires swift-proxy, but swift-proxy is in BLACK_LIST under graph.py
mumble-server: requires juju-info, but no subordinates are in the index
nagios: requires juju-info, but no subordinates are in the index
postgresql: requires directory-path, but no charms provide that interface
tomcat7: requires testing, but no official charms implement that interface

Charmrunner should probably skip the interfaces it can't match during graphing, but I'm not sure if that's the best way to handle this.

Revision history for this message
Antonio Rosales (arosales) wrote :

A few brainstorming ideas below:

Short term, if tests that have black list could the test runner skip these and mark that test status as "uncertain" meaning it didn't fail or pass, but has another condition. Write this to the log so folks investigating can tell this is a current limitation of the testing.

Long term should we file bugs against these specific charms (less glance) to resolve the requires section?


Marco Ceppi (marcoceppi)
Changed in charmrunner:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers