<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Oct 27, 2013 at 4:29 PM, Ilya Sviridov <span dir="ltr"><<a href="mailto:isviridov@mirantis.com" target="_blank">isviridov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Totally agree, however current concept supposes working with type and version as different entities, even if it is the attributes on one thing - the configuration.<br>
</div><div><br>The reason for storing it as separate models can be cases when we are going to use them separately.<br>
<br></div><div>Sounds really reasonable to keep it as one model, but another question comes to mind.<br></div><div>How 'list datastore_type' will look like. That is important because API should be in<span><span>ambiguous</span></span><span>.<br>
<br></span></div><div><span></span></div><div><span>Following openstack tenets, each entity exposed via API has an id and can referenced by it.<br></span></div><div><span>If we are storing datastore as one entity, we are not able to query versions or types only with their ids.<br>
<br></span></div><div><span>But it is agreed as API<br></span><br><span>/{tenant_id}/datastore_types<br></span><table><tbody><tr valign="top"><td><span>/{tenant_id}/datastore_types/{datastore_type}/versions<br>
</span></td></tr><tr valign="top"><td><span>/{tenant_id}/datastore_types/versions/{id}</span></td><td><br></td><td><br></td><td><br></td><td><br></td></tr></tbody></table>
<br></div></div></blockquote><div><br></div><div>I am wondering why we even need the last route. <span style="font-family:arial,sans-serif">/{tenant_id}/datastore_types/</span><span style="font-family:arial,sans-serif">versions/{id}</span></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">If we assume that a datastore_type is the parent resource of versions, we could change that route to: </span><span style="font-family:arial,sans-serif">/{tenant_id}/datastore_types/{datastore_type}/</span><font face="arial, sans-serif">versions/{id}. Although I don’t know if this route is even necessary - since listing all available versions of a certain type is all users really need.</font></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div><font face="arial, sans-serif">This will allow us to group the type and version, making version no longer independent as Nikhil suggests.</font></div><div>
<span style="font-family:arial,sans-serif"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div></div><div>So, with current concept it seems better to keep version and type as separate entities in database.<br></div><div></div><br></div><div class="gmail_extra"><div class="im"><br clear="all"><div>
<div dir="ltr"><font color="#888888"><div>
<span style>With best regards,<br>Ilya Sviridov<br></span><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><br><a href="http://www.mirantis.ru/" style="color:rgb(0,0,204)" target="_blank"></a></span></div>
</font></div></div>
<br><br></div><div><div class="h5"><div class="gmail_quote">On Fri, Oct 25, 2013 at 10:25 PM, Nikhil Manchanda <span dir="ltr"><<a href="mailto:nikhil@manchanda.me" target="_blank">nikhil@manchanda.me</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
It seems strange to me to treat both the datastore_type and version as<br>
two separate entities, when they aren't really independent of each<br>
other. (You can't really deploy a mysql type with a cassandra version,<br>
and vice-versa, so why have separate datastore-list and version-list<br>
calls?)<br>
<br>
I think it's a better idea to store in the db (and list) actual<br>
representations of the datastore type/versions that an image we can<br>
deploy supports. Any disambiguation could then happen based on what<br>
entries actually exist here.<br>
<br>
Let me illustrate what I'm trying to get at with a few examples:<br>
<br>
Database has:<br>
id | type | version | active<br>
----------------------------------<br>
a | mysql | 5.6.14 | 1<br>
b | mysql | 5.1.0 | 0<br>
c | postgres | 9.3.1 | 1<br>
d | redis | 2.6.16 | 1<br>
e | redis | 2.6.15 | 1<br>
f | cassandra | 2.0.1 | 1<br>
g | cassandra | 2.0.0 | 0<br>
<br>
Config specifies:<br>
default_datastore_id = a<br>
<br>
1. trove-cli instance create ...<br>
Just works - Since nothing is specified, this uses the<br>
default_datastore_id from the config (mysql 5.6.14 <a>) . No need for<br>
disambiguation.<br>
<br>
2. trove-cli instance create --datastore_id e<br>
The datastore_id specified always identifies a unique datastore type /<br>
version so no other information is needed for disambiguation. (In this<br>
case redis 2.6.15, identified by <e>)<br>
<br>
3. trove-cli instance create --datastore_type postgres<br>
The datastore_type in this case uniquely identifies postgres 9.3.1 <c>,<br>
so no disambiguation is necessary.<br>
<br>
4. trove-cli instance create --datastore_type cassandra<br>
In this case, there is only one _active_ datastore with the given<br>
datastore_type, so no further disambiguation is needed and cassandra<br>
2.0.1 <f> is uniquely identified.<br>
<br>
5. trove-cli instance create --datastore_type redis<br>
In this case, there are _TWO_ active versions of the specified<br>
datastore_type (2.6.16, and 2.6.17) so the call should return that<br>
further disambiguation _is_ needed.<br>
<br>
6. trove-cli instance create --datastore_type redis --datastore_version 2.6.16<br>
We have both datastore_type and datastore_version, and that uniquely<br>
identifies redis 2.6.16 <e>. No further disambiguation is needed.<br>
<br>
7. trove-cli instance create --datastore_type cassandra --version 2.0.0,<br>
or trove-cli instance create --datastore_id g<br>
Here, we are attempting to deploy a datastore which is _NOT_ active and<br>
this call should fail with an appropriate error message.<br>
<br>
Cheers,<br>
-Nikhil<br>
<div><div><br>
<br>
Andrey Shestakov writes:<br>
<br>
> 2. it can be confusing coz not clear to what type version belongs<br>
> (possible add "type" field in version).<br>
> also if you have default type, then specified version recognizes as<br>
> version of default type (no lookup in version.datastore_type_id)<br>
> but i think we can do lookup in version.datastore_type_id before pick<br>
> default.<br>
><br>
> 4. if default version is need, then it should be specified in db, coz<br>
> switching via versions can be frequent and restart service to reload<br>
> config all times is not good.<br>
><br>
> On 10/21/2013 05:12 PM, Tim Simpson wrote:<br>
>> Thanks for the feedback Andrey.<br>
>><br>
>> >> 2. Got this case in irc, and decided to pass type and version<br>
>> together to avoid confusing.<br>
>> I don't understand how allowing the user to only pass the version<br>
>> would confuse anyone. Could you elaborate?<br>
>><br>
>> >> 3. Names of types and maybe versions can be good, but in irc conversation rejected this case, i cant<br>
>> remember exactly reason.<br>
>> Hmm. Does anyone remember the reason for this?<br>
>><br>
>> >> 4. Actually, "active" field in version marks it as default in type.<br>
>> >>Specify default version in config can be usefull if you have more then<br>
>> one active versions in default type.<br>
>> If 'active' is allowed to be set for multiple rows of the<br>
>> 'datastore_versions' table then it isn't a good substitute for the<br>
>> functionality I'm seeking, which is to allow operators to specify a<br>
>> *single* default version for each datastore_type in the database. I<br>
>> still think we should still add a 'default_version_id' field to the<br>
>> 'datastore_types' table.<br>
>><br>
>> Thanks,<br>
>><br>
>> Tim<br>
>><br>
</div></div>>> ------------------------------------------------------------------------<br>
>> *From:* Andrey Shestakov [<a href="mailto:ashestakov@mirantis.com" target="_blank">ashestakov@mirantis.com</a>]<br>
>> *Sent:* Monday, October 21, 2013 7:15 AM<br>
>> *To:* OpenStack Development Mailing List<br>
>> *Subject:* Re: [openstack-dev] [Trove] How users should specify a<br>
<div><div>>> datastore type when creating an instance<br>
>><br>
>> 1. Good point<br>
>> 2. Got this case in irc, and decided to pass type and version together<br>
>> to avoid confusing.<br>
>> 3. Names of types and maybe versions can be good, but in irc<br>
>> conversation rejected this case, i cant remember exactly reason.<br>
>> 4. Actually, "active" field in version marks it as default in type.<br>
>> Specify default version in config can be usefull if you have more then<br>
>> one active versions in default type.<br>
>> But how match active version in type depends on operator`s<br>
>> configuration. And what if "default version in config" will marked as<br>
>> inactive?<br>
>><br>
>> On 10/18/2013 10:30 PM, Tim Simpson wrote:<br>
>>> Hello fellow Trovians,<br>
>>><br>
>>> There has been some good work recently to figure out a way to specify<br>
>>> a specific datastore when using Trove. This is essential to<br>
>>> supporting multiple datastores from the same install of Trove.<br>
>>><br>
>>> I have an issue with some elements of the proposed solution though,<br>
>>> so I decided I'd start a thread here so we could talk about it.<br>
>>><br>
>>> As a quick refresher, here is the blue print for this work (there are<br>
>>> some gists ammended to the end but I figured the mailing list would<br>
>>> be an easier venue for discussion):<br>
>>> <a href="https://wiki.openstack.org/wiki/Trove/trove-versions-types" target="_blank">https://wiki.openstack.org/wiki/Trove/trove-versions-types</a><br>
>>><br>
>>> One issue I have is with the way the instance create call will change<br>
>>> to support different data stores. For example, here is the post call:<br>
>>><br>
>>> """<br>
>>> {<br>
>>> "instance" : {<br>
>>> "flavorRef" : "2",<br>
>>> "name" : "as",<br>
>>> "datastore_type" : "e60153d4-8ac4-414a-ad58-fe2e0035704a",<br>
>>> "datastore_version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b",<br>
>>> "volume" : { "size" : "1" }<br>
>>> }<br>
>>> }<br>
>>> """<br>
>>><br>
>>> 1. I think since we have two fields in the instance object we should<br>
>>> make a new object for datastore and avoid the name prefixing, like this:<br>
>>><br>
>>> """<br>
>>> {<br>
>>> "instance" : {<br>
>>> "flavorRef" : "2",<br>
>>> "name" : "as",<br>
>>> "datastore": {<br>
>>> "type" : "e60153d4-8ac4-414a-ad58-fe2e0035704a",<br>
>>> "version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b"<br>
>>> }<br>
>>> "volume" : { "size" : "1" }<br>
>>> }<br>
>>> }<br>
>>> """<br>
>>><br>
>>> 2. I also think a datastore_version alone should be sufficient since<br>
>>> the associated datastore type will be implied:<br>
>>><br>
>>> """<br>
>>> {<br>
>>> "instance" : {<br>
>>> "flavorRef" : "2",<br>
>>> "name" : "as",<br>
>>> "datastore": {<br>
>>> "version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b"<br>
>>> }<br>
>>> "volume" : { "size" : "1" }<br>
>>> }<br>
>>> }<br>
>>> """<br>
>>><br>
>>> 3. Additionally, while a datastore_type should have an ID in the<br>
>>> Trove infastructure database, it should also be possible to pass just<br>
>>> the name of the datastore type to the instance call, such as "mysql"<br>
>>> or "mongo". Maybe we could allow this in addition to the ID? I think<br>
>>> this form should actually use the argument "type", and the id should<br>
>>> then be passed as "type_id" instead.<br>
>>><br>
>>> """<br>
>>> {<br>
>>> "instance" : {<br>
>>> "flavorRef" : "2",<br>
>>> "name" : "as",<br>
>>> "datastore": {<br>
>>> "type" : "mysql",<br>
>>> "version" : "94ed1f9f-6c1a-4d6e-87e9-04ecff37b64b"<br>
>>> }<br>
>>> "volume" : { "size" : "1" }<br>
>>> }<br>
>>> }<br>
>>><br>
>>> """<br>
>>><br>
>>> 4. Additionally, in the current pull request to implement this it is<br>
>>> possible to avoid passing a version, but only if no more than one<br>
>>> version of the datastore_type exists in the database.<br>
>>><br>
>>> I think instead the datastore_type row in the database should also<br>
>>> have a "default_version_id" property, that an operator could update<br>
>>> to the most recent version or whatever other criteria they wish to<br>
>>> use, meaning the call could become this simple:<br>
>>><br>
>>> """<br>
>>> {<br>
>>> "instance" : {<br>
>>> "flavorRef" : "2",<br>
>>> "name" : "as",<br>
>>> "datastore": {<br>
>>> "type" : "mysql"<br>
>>> }<br>
>>> "volume" : { "size" : "1" }<br>
>>> }<br>
>>> }<br>
>>> """<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Tim<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>