cache management API is hardcoded under /v1

[Eoghan Glynn]

The cachemanagement API is hardcoded to use v1:

  https://github.com/openstack/glance/blob/master/glance/api/middleware/cache_manage.py#L36

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)]

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

$ curl -H "X-Auth-Token: $tok" http://10.130.50.34:9292/v1/cached_images | 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": "http://10.130.50.34:9292/v2/",
                    "rel": "self"
                }
            ],
            "status": "CURRENT"
        }
    ]
}

[Mark Washenberger (markwash)]

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.

[Mark Washenberger (markwash)]

Again, this is a valid issue. I just see this particular bug as being superseded by this blueprint: https://blueprints.launchpad.net/glance/+spec/expose-cache-management-differently

[Flavio Percoco (flaper87)]

Agreed.

I started summarizing the ideas here:

https://blueprints.launchpad.net/glance/+spec/glance-cache-path