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 <[email protected]> > +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 [[email protected]] > *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 <[email protected]> > >> >> >> >> On Sun, Oct 27, 2013 at 4:29 PM, Ilya Sviridov >> <[email protected]>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 < >>> [email protected]> 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 [[email protected]] >>>> >> *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 >>>> >>> [email protected] >>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> OpenStack-dev mailing list >>>> >> [email protected] >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> > _______________________________________________ >>>> > OpenStack-dev mailing list >>>> > [email protected] >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
