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 [ashesta...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
