Open Stack

We're at the trove meetup for the rest of this week but you should speak
with Kaleb Pomeroy from Rackspace.  He's generated some code on this
particular subject.


On Wed, Feb 19, 2014 at 11:11 AM, Denis Makogon <dmakogon at mirantis.com>wrote:

> Goodday OpenStack DBaaS communtiy.
>
> I'd like to start topic related to design of capabilities [1].
>
> This question was raised when multiple datastores where integrated into
> Trove (such as redis, cassandra, mongo in instance modes). We encountered a
> the problem when specific datastore doesn't support operations that are the
> part of Trove API (core and extension). After some discussions with the
> community we decided to implement "capabilities" feature. Basicaly,
> "capabilities" is the list of operations acceptable for chosen "object". To
> be accurate,  "capabilities" is the API for listing available Trove
> API(core and extensions) per some kind of an identifier.
>
> Design.
>
> I'd like to split up all tasks into small peaces:
>
>
>    1.
>
>    Nameing convintion.<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.dqx5s9nxd86g>
>    2.
>
>    DSL for writing reference to available capabilities.<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.a86gyngvxgek>
>    3.
>
>    Сustody strategy. How and what to store at the back-end?<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.p3kja3s8zex>
>    4.
>
>    Pinning to datastore or version?<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.mvusz3lj5res>
>    5.
>
>    How to load  actual API reference?<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.df6yrbqny8te>
>    6.
>
>    Default capabilities. What operations are allowed by default?<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.gjahbyoqoq5d>
>    7.
>
>    Capablities API.<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.ihzh5pv7pmci>
>    8.
>
>    Capabilities Management API.<https://docs.google.com/a/mirantis.com/document/d/1FDhenfF47UYdiqTr5dGHSG_Gk828yFuvew92I9qil5I/edit#heading=h.paouley6yndv>
>
>
> Naming convention
>
> Suggestions:
>
>    1.
>
>    Filename convension:
>
> {datastore or datastore_version_manager}.capabilities
>
>    1.
>
>    Attribute convension:
>
> Trove-"API-section":
>
> - method: Identifier
>
>     Available sections: instance, backip, users, schemes.
>
>     Capability Identifier: ALLOWED/BLOCKED
>  DSL for writing reference to available capabilities
>
> There are several options of DSL's that can be chosen for writing
> capabilities references, options:
>
>    1.
>
>    JSON.
>    2.
>
>    YAML.
>    3.
>
>    XML.
>
>     Personaly i'd like to choose YAML as appropriate DSL. Described
> capabilities would look like: mysql.capabilities
>
> Trove-Instance:
>
> - create: ALLOWED
>
> - list: BLOCKED
>
> - delete: ALLOWED
>
> Trove-Backup:
>
> - create: BLOCKED
>
> Trove-Users:
>
> - create: BLOCKED
>
> Сustody strategy. How and what to store at the back-end ?
>
> Before suggesting database table scheme i'd like to describe what we are
> going to store. It would be better to store only blocked capabilities, its
> cheaper, instead of storing all capabilities, either blocked and allowed.
>
> Backend table scheme.
>
> Table 1 - Capabilities table scheme
>
> Datastore or Datastore version manager
>
> Capabilities
>
> datastore or manager
>
> "Trove-"API-section":
>
>                      - method: Identifier"
>
>     Where Identifier could be ALLOWED or BLOCKED
>  Pinning to datastore or datastore version?
>
> As you can see from previous topics, it would be better to pin
> capabilities directly to datastore version, since one manager could be
> assigned to multiple datastore versions.
>
>     So, capabilities backend table scheme would have next desription:
>
>
>    -
>
>    datastrove_version_manager:
>
> name: manager, Foreing key from DatastoreVersion table;
>
> type: String.
>
>    -
>
>    capabilities:
>
> name: capabilities;
>
> type: Text.
>
> How to load actual API reference?
>
>     According to previous topics i forsee the next way of discovering
> actual capabilities at runtime:
>
>     Since YAML format perfectly could be loaded as Python dictionary, the
> easiest way is to merge two dictionaries.
>
>     Example:
>
>     default_capabilities = (CapabilitiesModel.
>
>             load_defaults(manager=datastore_version.manager))
>
> blocked_capabilities = (CapabilitiesModel.
>
> load_blocked(manager=datastore_version.manager))
>
>     actual_capabilities = dict(chain(
>
> default_capabilities.iteritems(),
>
> blocked_capabilities.iteritems()
>
> )
>
> )
>
>
>
>  Default capabilities. What operations are allowed by default?
>
>
>
> Lets take a look at those datastore types that Trove supports. For now it
> supports: mysql, redis, cassandra, mongo.
>
>     Not so long ago community team decided to bring up Capablities matrix
> [2]. By default each datastore should support core API [3] and extensions
> API [4] are optional. So, i'd like to suggest to mark core API capabilities
> as ALLOWED, and extensions API capabilities as BLOCKED.
> Capabilities API
>
> Task:     describe actual capabilities per datastore version manager
>
> HTTP method:     GET
>
> Method name:     show
>
> Route:     /{tenant_id}/capabilities/{datastore_version_id}
>
> CLI call:     trove capabilities-show --datastore-version <UUID>
>
> Task:     list all actual capabilities
>
> HTTP method:     GET
>
> Method name:     index
>
> Route:     /{tenant_id}/capabilities/
>
> CLI call:     trove capabilities-list
> Capabilities Management API
>
>
>
> My suggestion is to add capabilities management API to trove-manageutility (for the first iteration).
>
> trove-manage capabilities_update <datastore_manager> <Trove-"API-section">
> <method> <Identifier>
>
> where:
>
> <datastore_manager> - datastore manager (variants: mysql, redis,
> cassandra, mongo, percona);
>
> <Trove-"API-section">  - part of API (core or extension, possible
> variants: Trove-Instance, Trove-Backup, Trove-Users, etc);
>
> <method> - method available for given section of Trove API (variants:
> create, delete, list, show etc)
>
>     <Identifier> - identifier that marks method from API section as
> ALLOWED/BLOCKED
>
>
> [1] https://wiki.openstack.org/wiki/Trove/trove-capabilities
>
> [2] https://wiki.openstack.org/wiki/Trove/DatastoreCompatibilityMatrix
>
> [3]
> https://wiki.openstack.org/wiki/Trove/DatastoreCompatibilityMatrix#API_Matrix
>
> [4]
> https://wiki.openstack.org/wiki/Trove/DatastoreCompatibilityMatrix#Extensions_Matrix
>
>
>
> Best regards
>
> Denis Makogon.
>
> <https://wiki.openstack.org/wiki/Trove/DatastoreCompatibilityMatrix#Extensions_Matrix>
>
>
> _______________________________________________
> 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/20140219/112a4151/attachment.html>