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 <[email protected]> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Date: Monday, February 3, 2014 9:54 AM To: OpenStack Development Mailing List <[email protected]> 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/> [email protected] <mailto:[email protected]> _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
