Image cache middleware order should not matter in paste pipeline
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Glance |
Fix Released
|
Low
|
Brian Waldon |
Bug Description
If I use the following paste pipeline:
[pipeline:
pipeline = versionnegotiation authtoken auth-context cachemanage cache apiv1app
...the glance-api daemon throws this traceback:
Traceback (most recent call last):
File "bin/glance-api", line 48, in <module>
app = config.
File "/opt/stack/
app = wsgi.paste_
File "/opt/stack/
return deploy.
File "/usr/lib/
return loadobj(APP, uri, name=name, **kw)
File "/usr/lib/
return context.create()
File "/usr/lib/
return self.object_
File "/usr/lib/
app = filter(app)
File "/opt/stack/
return factory(app, self.conf, **local_conf)
File "/opt/stack/
map = app.map
AttributeError: 'CacheFilter' object has no attribute 'map'
If I reverse the order of cache and cachemanage, the api comes up correctly. The order of the middleware should not matter.
Changed in glance: | |
importance: | Undecided → Low |
Changed in glance: | |
milestone: | none → essex-rc1 |
Changed in glance: | |
status: | Fix Committed → Fix Released |
Changed in glance: | |
milestone: | essex-rc1 → 2012.1 |
It appears that the cachemanage middleware depends on the 'map' attribute that the apiv1app sets up in the pipeline. We need to break that dependency.