[openstack-dev] [Trove] How users should specify a datastore type when creating an instance
Denis Makogon
dmakogon at mirantis.com
Mon Oct 28 23:34:12 UTC 2013
Oslo config files is the higher abstraction of trove service configuration.
Since common/cfg.py configuration is almost independent from *.conf files,
then yes, we could use parameters from there, but, to be precise, we should
intialize that parameter in a right way, and this means we should store
dictionary with managers fq classname at taskmanager.conf, or even at
trove.conf - it is up to us.
2013/10/29 Tim Simpson <tim.simpson at rackspace.com>
> +1 to Vipul's suggestion.
>
> > 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.
>
> I think using the config files like that goes too far- there was an
> earlier email by Ilya which touched on something similar. In general I
> think if we plan on storing rich configuration details for potentially
> dozens of database types and versions then plain text files may be an
> option but we shouldn't try to morph the current Oslo config files to serve
> that purpose.
>
>
>
>
> ------------------------------
> *From:* Denis Makogon [dmakogon at mirantis.com]
> *Sent:* Monday, October 28, 2013 1:05 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Trove] How users should specify a
> datastore type when creating an instance
>
> 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
>>
>>
>
> _______________________________________________
> 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/20131029/68585e87/attachment.html>
More information about the OpenStack-dev
mailing list