cache management API is hardcoded under /v1

Bug #1135537 reported by Eoghan Glynn on 2013-02-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Flavio Percoco

Bug Description

The cachemanagement API is hardcoded to use v1:

whereas if the v2 API is enabled, but not v1, this is problematic as clients would want to use v2 across the board.

Mark Washenberger (markwash) wrote :

With v1 disabled, this is what happens when you try to GET /v1/cached_images

$ curl -H "X-Auth-Token: $tok" | python -m json.tool
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 119 100 119 0 0 25142 0 --:--:-- --:--:-- --:--:-- 29750
    "versions": [
            "id": "v2.0",
            "links": [
                    "href": "",
                    "rel": "self"
            "status": "CURRENT"

Changed in glance:
status: New → Triaged
importance: Undecided → High
Changed in glance:
assignee: nobody → Flavio Percoco Premoli (flaper87)
Mark Washenberger (markwash) wrote :

After giving this some thought, I don't think we should fix this bug by simply porting the cache management to v2.

Cache management is an inherently local action, and doesn't make sense living alongside the v2 api which reports status for coarser entities like regional store or the glance db.

Rather than fixing this bug, I think we should put together a blueprint for exposing cache management outside of the main glance api.

Changed in glance:
status: Triaged → Won't Fix
Mark Washenberger (markwash) wrote :

Again, this is a valid issue. I just see this particular bug as being superseded by this blueprint:

Flavio Percoco (flaper87) wrote :


I started summarizing the ideas here:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers