[sharding] Admin and user storage operations should not be in the same driver.

[Kurt Griffiths]

Conceptually, it makes more sense to service the admin API with its own driver, rather than sharing with the queues app. Two different apps, different backend DBs, different auth etc.

E.g.:

    class PublicDriver(...):
        @property
        def _queue_controller(self): ...
        @property
        def _message_controller(self): ...
        @property
        def _claim_controller(self): ...

    class AdminDriver(...):
        @property
        def shards_controller(self): ...
        @property
        def catalogue_controller(self): ...

[Allele Dev (alleledev)]

DataDriver and ControlDriver ended up making a lot more sense. Admin/Public is all about the transport layer. The storage layer only cares about controls and data.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/52160
Committed: http://github.com/openstack/marconi/commit/4f5de4b23fde855c1b4ad2b90242bad9d2070437
Submitter: Jenkins
Branch: master

commit 4f5de4b23fde855c1b4ad2b90242bad9d2070437
Author: Alejandro Cabrera <email address hidden>
Date: Wed Oct 16 12:54:55 2013 -0400

    feat: add catalogue storage driver for queues

    The upcoming sharding feature requires a catalogue storage driver very
    similar to that used by the proxy. This patch ports the proxy
    catalogue storage driver to the queues storage space and updates the
    semantics accordingly. Specifically, the queues catalogue maintains a
    mapping from project/queue to shard identifier.

    Unit tests and helpers have been updated accordingly. The sqlite
    portion of this is still to be done, and is reserved for a future
    patch.

    The faulty storage drivers has been given the appropriate
    catalogue_controller impls.

    Furthermore, minor py3k updates were added: metaclass using
    six.add_metaclass.

    Change-Id: I380d028520e9a712064810a15e2c6576de67e485
    Partially-implements: blueprint storage-sharding
    Closes-Bug: #1241686