Open Stack

It seems strange to me to treat both the datastore_type and version as
two separate entities, when they aren't really independent of each
other. (You can't really deploy a mysql type with a cassandra version,
and vice-versa, so why have separate datastore-list and version-list
calls?)

I think it's a better idea to store in the db (and list) actual
representations of the datastore type/versions that an image we can
deploy supports. Any disambiguation could then happen based on what
entries actually exist here.

Let me illustrate what I'm trying to get at with a few examples:

Database has:
id | type      | version | active
----------------------------------
a  | mysql     | 5.6.14  |   1
b  | mysql     | 5.1.0   |   0
c  | postgres  | 9.3.1   |   1
d  | redis     | 2.6.16  |   1
e  | redis     | 2.6.15  |   1
f  | cassandra | 2.0.1   |   1
g  | cassandra | 2.0.0   |   0

Config specifies:
default_datastore_id = a

1. trove-cli instance create ...
Just works - Since nothing is specified, this uses the
default_datastore_id from the config (mysql 5.6.14 <a>) . No need for
disambiguation.

2. trove-cli instance create --datastore_id e
The datastore_id specified always identifies a unique datastore type /
version so no other information is needed for disambiguation. (In this
case redis 2.6.15, identified by <e>)

3. trove-cli instance create --datastore_type postgres
The datastore_type in this case uniquely identifies postgres 9.3.1 <c>,
so no disambiguation is necessary.

4. trove-cli instance create --datastore_type cassandra
In this case, there is only one _active_ datastore with the given
datastore_type, so no further disambiguation is needed and cassandra
2.0.1 <f> is uniquely identified.

5. trove-cli instance create --datastore_type redis
In this case, there are _TWO_ active versions of the specified
datastore_type (2.6.16, and 2.6.17) so the call should return that
further disambiguation _is_ needed.

6. trove-cli instance create --datastore_type redis --datastore_version 2.6.16
We have both datastore_type and datastore_version, and that uniquely
identifies redis 2.6.16 <e>. No further disambiguation is needed.

7. trove-cli instance create --datastore_type cassandra --version 2.0.0,
or trove-cli instance create --datastore_id g
Here, we are attempting to deploy a datastore which is _NOT_ active and
this call should fail with an appropriate error message.

Cheers,
-Nikhil


Andrey Shestakov writes:

> 2. it can be confusing coz not clear to what type version belongs
> (possible add "type" field in version).
> also if you have default type, then specified version recognizes as
> version of default type (no lookup in version.datastore_type_id)
> but i think we can do lookup in version.datastore_type_id before pick
> default.
>
> 4. if default version is need, then it should be specified in db, coz
> switching via versions can be frequent and restart service to reload
> config all times is not good.
>
> On 10/21/2013 05:12 PM, Tim Simpson wrote:
>> Thanks for the feedback Andrey.
>>
>> >> 2. Got this case in irc, and decided to pass type and version
>> together to avoid confusing.
>> I don't understand how allowing the user to only pass the version
>> would confuse anyone. Could you elaborate?
>>
>> >> 3. Names of types and maybe versions can be good, but in irc conversation rejected this case, i cant
>> remember exactly reason.
>> Hmm. Does anyone remember the reason for this?
>>
>> >> 4. Actually, "active" field in version marks it as default in type.
>> >>Specify default version in config can be usefull if you have more then
>> one active versions in default type.
>> If 'active' is allowed to be set for multiple rows of the
>> 'datastore_versions' table then it isn't a good substitute for the
>> functionality I'm seeking, which is to allow operators to specify a
>> *single* default version for each datastore_type in the database. I
>> still think we should still add a 'default_version_id' field to the
>> 'datastore_types' table.
>>
>> Thanks,
>>
>> Tim
>>
>> ------------------------------------------------------------------------
>> *From:* Andrey Shestakov [ashestakov at mirantis.com]
>> *Sent:* Monday, October 21, 2013 7:15 AM
>> *To:* OpenStack Development Mailing List
>> *Subject:* Re: [openstack-dev] [Trove] How users should specify a
>> datastore type when creating an instance
>>
>> 1. Good point
>> 2. Got this case in irc, and decided to pass type and version together
>> to avoid confusing.
>> 3. Names of types and maybe versions can be good, but in irc
>> conversation rejected this case, i cant remember exactly reason.
>> 4. Actually, "active" field in version marks it as default in type.
>> Specify default version in config can be usefull if you have more then
>> one active versions in default type.
>> But how match active version in type depends on operator`s
>> configuration. And what if "default version in config" will marked as
>> inactive?
>>
>> On 10/18/2013 10:30 PM, Tim Simpson wrote:
>>> Hello fellow Trovians,
>>>
>>> There has been some good work recently to figure out a way to specify
>>> a specific datastore  when using Trove. This is essential to
>>> supporting multiple datastores from the same install of Trove.
>>>
>>> I have an issue with some elements of the proposed solution though,
>>> so I decided I'd start a thread here so we could talk about it.
>>>
>>> As a quick refresher, here is the blue print for this work (there are
>>> some gists ammended to the end but I figured the mailing list would
>>> be an easier venue for discussion):
>>> https://wiki.openstack.org/wiki/Trove/trove-versions-types
>>>
>>> One issue I have is with the way the instance create call will change
>>> to support different data stores. For example, here is the post call:
>>>
>>> """
>>> {
>>>       "instance" : {
>>>       "flavorRef" : "2",
>>>       "name" : "as",
>>>       "datastore_type" : "e60153d4-8ac4-414a-ad58-fe2e0035704a",
>>>       "datastore_version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b",
>>>       "volume" : { "size" : "1" }
>>>     }
>>> }
>>> """
>>>
>>> 1. I think since we have two fields in the instance object we should
>>> make a new object for datastore and avoid the name prefixing, like this:
>>>
>>> """
>>> {
>>>      "instance" : {
>>>       "flavorRef" : "2",
>>>       "name" : "as",
>>>       "datastore": {
>>>             "type" : "e60153d4-8ac4-414a-ad58-fe2e0035704a",
>>>             "version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b"
>>>       }
>>>       "volume" : { "size" : "1" }
>>>     }
>>> }
>>> """
>>>
>>> 2. I also think a datastore_version alone should be sufficient since
>>> the associated datastore type will be implied:
>>>
>>> """
>>> {
>>>       "instance" : {
>>>       "flavorRef" : "2",
>>>       "name" : "as",
>>>       "datastore": {
>>>             "version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b"
>>>       }
>>>       "volume" : { "size" : "1" }
>>>     }
>>> }
>>> """
>>>
>>> 3. Additionally, while a datastore_type should have an ID in the
>>> Trove infastructure database, it should also be possible to pass just
>>> the name of the datastore type to the instance call, such as "mysql"
>>> or "mongo". Maybe we could allow this in addition to the ID? I think
>>> this form should actually use the argument "type", and the id should
>>> then be passed as "type_id" instead.
>>>
>>> """
>>> {
>>>       "instance" : {
>>>       "flavorRef" : "2",
>>>       "name" : "as",
>>>       "datastore": {
>>>             "type" : "mysql",
>>>             "version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b"
>>>       }
>>>       "volume" : { "size" : "1" }
>>>     }
>>> }
>>>
>>> """
>>>
>>> 4. Additionally, in the current pull request to implement this it is
>>> possible to avoid passing a version, but only if no more than one
>>> version of the datastore_type exists in the database.
>>>
>>> I think instead the datastore_type row in the database should also
>>> have a "default_version_id" property, that an operator could update
>>> to the most recent version or whatever other criteria they wish to
>>> use, meaning the call could become this simple:
>>>
>>> """
>>> {
>>>       "instance" : {
>>>       "flavorRef" : "2",
>>>       "name" : "as",
>>>       "datastore": {
>>>             "type" : "mysql"
>>>       }
>>>       "volume" : { "size" : "1" }
>>>     }
>>> }
>>> """
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>>
>>> Tim
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev