Open Stack

Hello, Kevin.

1. Users/Databases CRUD operation are not the part of Trove core API.

2. And i'm not suggesting to define same extension, if database supports
ACL and storage distinction developer would be able to define
it's own ReST routes for all his needs in term of CRUD operations.

3. There's problem on rising exception on guest side, each exception
returns stacktrace to client side,
that why this suggested implementation makes possible to handle reporting
to end-user without envolving
guest service in the process of information delivery. Example - [1]

4. About support matrix - it defined only for first steps (initial commit).
In future all possible functions would be implemented.

Main idea of patchset and this convo is to discover huge problem - routes
for extensions should not be datastore-specific, they should be, mostly,
uniq and background implementation should be datastore orientied.


[1] https://gist.github.com/denismakogon/8788333




2014/2/3 Kevin Conway <kevinjacobconway at gmail.com>

> 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.
>
>    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.
>    3.
>
>    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
>
>     [2] 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
>
> www.mirantis.ru
>
> dmakogon at mirantis.com
> _______________________________________________ OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> 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/32524cd2/attachment.html>