Open Stack

Denis,

It seems that you are hitting on a couple of points here. 1) You aren't a
fan of the fact that calls to user/db are routed through an extensions
written for mysql. 2) This creates a conflict when a datastore does not
support those calls. I am confused about your solution.

Your suggestion is to require each datastore manager to define the same
extension and implement the API even if it only returns NotImplemented. If
every datastore must define the same API extension then it is not an
extension. It is a part of the core API. If anything, we should be promoting
the user and database API to core since we already require that datastore
account for it in some way.

As far as communicating to a user whether or not their datastore supports an
API call, I thought we already solved this problem by 1) setting the guest
agents to raise NotImplmentedError for unsupported calls, 2) starting work
on a capabilities api:
https://wiki.openstack.org/wiki/Trove/trove-capabilities, and 3) drafting
the feature compatibility of our current target data stores at
https://wiki.openstack.org/wiki/Trove/DatastoreCompatibilityMatrix.

If the question, instead, is "How do we provide single-datastore specific
functionality in Trove?" then that is a whole different conversation.

** This is a side note for whoever added it, but I am also confused why
MongoDB and Cassandra cannot support the users API according to the
compatibility matrix. MongoDB has user/role management and even has a
superuser which is equivalent to the mysql root. Cassandra also supports
user/pass authentication as a part of its simple-auth protocol.

From:  Denis Makogon <dmakogon at mirantis.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date:  Monday, February 3, 2014 9:54 AM
To:  OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject:  [openstack-dev] [Trove] API extention update in order to support
multi-databases integration

Goodday, OpenStack DBaaS users/contributors.


    I'd like to start topic related to refactoring of API extensions. Since
Trove already supports more than one db engines (mysql and redis in
single-instance mode).


    At this moment if contributors will decide that one of the integrated db
engines would support users/databases CRUD operations they will come into
the issue of non-pluggable extensions for described operations. Here [1] you
can see that users/databases CRUD operations will go through routes defined
for mysql database integration.
    
    I would like to suggest more flexible mechanism for such API extensions:
1. Extensions should be implemented per datastore manager, such as mysql,
redis, cassandra, mongodb.
2. 
3. ReST service routes for API extensions should be common for all of
datastores. It means that implemention should be imported/used according to
uniq attribute, best option for such attribute ­ datastore manager.
4. 
5. Even if datastore doesn't supports users ACL or storage distinction
(databases in terms of mysql, keyspaces in terms of cassandra) API extension
should be implemented, each method should raise NotImplmented exception with
meaningful message ³Not supported².


    As you can see at [2], mechanism implemented according to rules given
above. So, I would like to hear all your thoughts about that.


    [1] 
https://github.com/openstack/trove/blob/master/trove/extensions/routes/mysql
.py 
<https://github.com/openstack/trove/blob/master/trove/extensions/routes/mysq
l.py> 
    [2] https://review.openstack.org/70742
<https://review.openstack.org/70742>

 <https://review.openstack.org/70742>
 <https://review.openstack.org/70742>
Best regards,
Denis Makogon
Mirantis, Inc.


Kharkov, Ukraine
www.mirantis.com <http://www.mirantis.com/>
www.mirantis.ru <http://www.mirantis.ru/>
dmakogon at mirantis.com <mailto:dmakogon at mirantis.com>
_______________________________________________ OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140203/ae1ec2d2/attachment.html>