[openstack-dev] [Trove] How users should specify a datastore type when creating an instance

Denis Makogon dmakogon at mirantis.com
Mon Oct 28 06:05:07 UTC 2013


Small suggestion on listing datastore_type:
Since all compabilities based upon config, we could send response to user
based upon available guestagent managers, but this means, that all
datastore managers parameter should migrate to taskmanager.
Manager description(fq classpath) would delivered to instance through
guest_info.


2013/10/28 Vipul Sabhaya <vipuls at gmail.com>

>
>
>
> On Sun, Oct 27, 2013 at 4:29 PM, Ilya Sviridov <isviridov at mirantis.com>wrote:
>
>> 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.
>>
>> The reason for storing it as separate models can be cases when we are
>> going to use them separately.
>>
>> Sounds really reasonable to keep it as one model, but another question
>> comes to mind.
>> How 'list datastore_type' will look like. That is important because API
>> should be inambiguous.
>>
>> Following openstack tenets, each entity exposed via API has an id and can
>> referenced by it.
>> If we are storing datastore as one entity, we are not able to query
>> versions or types only with their ids.
>>
>> But it is agreed as API
>>
>> /{tenant_id}/datastore_types
>> /{tenant_id}/datastore_types/{datastore_type}/versions
>> /{tenant_id}/datastore_types/versions/{id}
>>
>>
>>
>>
>>
> I am wondering why we even need the last route.
> /{tenant_id}/datastore_types/versions/{id}
>
> If we assume that a datastore_type is the parent resource of versions, we
> could change that route to: /{tenant_id}/datastore_types/{datastore_type}/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.
>
> This will allow us to group the type and version, making version no longer
> independent as Nikhil suggests.
>
> So, with current concept it seems better to keep version and type as
>> separate entities in database.
>>
>>
>>  With best regards,
>> Ilya Sviridov
>>
>> <http://www.mirantis.ru/>
>>
>>
>> On Fri, Oct 25, 2013 at 10:25 PM, Nikhil Manchanda <nikhil at manchanda.me>wrote:
>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131028/c0668039/attachment.html>


More information about the OpenStack-dev mailing list