Create a new, db_api compliant, API for the Registry service

Registered by Flavio Percoco

In order to address blueprint registry-db-driver a new API is needed for the registry service. This API must be compliant with current db_api in terms of input parameters and responses, in order to be capable of wrapping it in a db driver and support legacy deployments.

The idea is to make it easier to implement new methods to the database API without having to modify the registry's API.

The benefits of doing so are:
1) it reduces the places where things need to be modified when implementing new features in the DB side

2) It reduces duplicated code

3) This will help migrating Glance's API v1 to use the database driver, which will allow users using glance-api v1 to deprecate the registry if they whish so.

RPC-over-HTTP has been chosen instead of a message-broker because it doesn't make sense to add more dependencies (MB and everything related to it) just for this feature.

Blueprint information

Flavio Percoco
Flavio Percoco
Flavio Percoco
Series goal:
Accepted for havana
Milestone target:
milestone icon 2013.2
Started by
Flavio Percoco
Completed by
Flavio Percoco

Related branches



Gerrit topic:,topic:bp/registry-api-v2,n,z

Addressed by:
    Make "private" functions that shouldn't be exported

Addressed by:
    Create package for registry's client

Addressed by:
    Implement registry API v2

Would it be possible to spell out the requirements/motivation for this. This seems to be part of the effort to kill the registry service, but this is putting a lot more work into that very service. I am sure there are good reason but it would be helpful if those reasons were spelled out for the community.

After push back on the original blueprint to kill the registry service, some thought was given to a somewhat more limited goal: Make the registry service entirely optional, even for glance api v1. The rough outline is this:

1) Expose a v2 registry that is 100% compatible with the db api
2) Create a registry db driver that serves db api requests by asking the registry
3) Port glance api v1 to use the db api abstraction rather than the registry, though you can still use the registry indirectly via the registry v2 db driver.
4) Deprecate/ditch the v1 registry

In the process, folks who want to use the registry can also use it as the backing for v2 of the image service api. (IIRC, the main motivation was that people wanted to limit the number of servers in their deployment that have db user credentials).

Perhaps the kill-registry bp needs to be updated to reflect this plan?

Makes sense. kill-registry is a bit confusing for folks that don't know the context.


I agree that changing the name would be a good idea, because the goal seems to be explicitly not to kill the registry but to enhance it so that it can be available to v2.

Addressed by:
    Implement Registry's Client V2


Work Items

Work items:
Make "private" some db_api functions: DONE
Create API V2: DONE
Update Registry client: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.