Create a new, db_api compliant, API for the Registry service
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
- Status:
- Complete
- Approver:
- Flavio Percoco
- Priority:
- High
- Drafter:
- Flavio Percoco
- Direction:
- Approved
- Assignee:
- Flavio Percoco
- Definition:
- Approved
- Series goal:
- Accepted for havana
- Implementation:
-
Implemented
- Milestone target:
-
2013.2
- Started by
- Flavio Percoco
- Completed by
- Flavio Percoco
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Make "private" functions that shouldn't be exported
Addressed by: https:/
Create package for registry's client
Addressed by: https:/
Implement registry API v2
<jbresnah>
Would it be possible to spell out the requirements/
</jbresnah>
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?
-markwash
Makes sense. kill-registry is a bit confusing for folks that don't know the context.
-flaper87
<jbresnah>
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.
</jbresnah>
Addressed by: https:/
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.
