gt; that purpose.
>
>
>
>
> --
> *From:* Denis Makogon [dmako...@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
> da
ion 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
>>
>>
ck 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. Nam
ions 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.
>> >> >&
t; >> '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 shoul
a 'default_version_id' field to the
>> 'datastore_types' table.
>>
>> Thanks,
>>
>> Tim
>>
>>
>> *From:* Andrey Shestakov [ashesta...@mirantis.com]
>> *Sen
abase that would be looked up
> similar to how we load template files on demand.
>
> - Tim
> --
> *From:* Ilya Sviridov [isviri...@mirantis.com]
> *Sent:* Thursday, October 24, 2013 7:40 AM
> *To:* OpenStack Development Mailing List
> *Subject:* R
Sent: Thursday, October 24, 2013 7:40 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type
when creating an instance
So, we have 2 places for configuration management - database and config file
Config file for tunning all datas
So, we have 2 places for configuration management - database and config file
Config file for tunning all datasource type behavior during installation
and database for all changeable configurations during usage and
administration of Trove installation.
Database usecases:
- update/custom image
- up
On Oct 23, 2013, at 10:54 AM, Ilya Sviridov wrote:
> Besides the strategy of selecting the default behavior.
>
> Let me share with you my ideas of configuration management in Trove and how
> the datastore concept can help with that.
>
> Initially there was only one database and all configurati
Besides the strategy of selecting the default behavior.
Let me share with you my ideas of configuration management in Trove and how
the datastore concept can help with that.
Initially there was only one database and all configuration was in one
config file.
With adding of new databases, heat prov
On Oct 22, 2013, at 9:34 AM, Tim Simpson wrote:
> > It's not intuitive to the User, if they are specifying a version alone.
> > You don't boot a 'version' of something, with specifying what that some
> > thing is. I would rather they only specified the datastore_type alone, and
> > not have
t Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type
when creating an instance
On Mon, Oct 21, 2013 at 2:04 PM, Michael Basnight
mailto:mbasni...@gmail.com>> wrote:
On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote:
>>> 2. I also think
a...@mirantis.com]
Sent: Monday, October 21, 2013 4:40 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type
when creating an instance
On Mon, Oct 21, 2013 at 11:40 PM, Tim Simpson wrote:
>
> >> 4. Additionally, i
or not found status code.
From: Michael Basnight [mbasni...@gmail.com]
Sent: Monday, October 21, 2013 4:05 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore
type when creating an instance
On Oct 21, 2013, at 1:57 PM
gmail.com]
Sent: Monday, October 21, 2013 4:04 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore
type when creating an instance
On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote:
>>> 2. I also think a datastore_versi
On Mon, Oct 21, 2013 at 2:04 PM, Michael Basnight wrote:
>
> On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote:
>
> >>> 2. I also think a datastore_version alone should be sufficient since
> the associated datastore type will be implied:
> >
> >> When i brought this up it was generally discussed as b
On Mon, Oct 21, 2013 at 11:40 PM, Tim Simpson wrote:
>
> >> 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 datasto
On Oct 21, 2013, at 1:57 PM, Nikhil Manchanda wrote:
>
> The image approach works fine if Trove only supports deploying a single
> datastore type (mysql in your case). As soon as we support
> deploying more than 1 datastore type, Trove needs to have some knowledge
> of which guestagent manager c
On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote:
>>> 2. I also think a datastore_version alone should be sufficient since the
>>> associated datastore type will be implied:
>
>> When i brought this up it was generally discussed as being confusing. Id
>> like to use type and rely on having a def
The image approach works fine if Trove only supports deploying a single
datastore type (mysql in your case). As soon as we support
deploying more than 1 datastore type, Trove needs to have some knowledge
of which guestagent manager classes to load. Hence the need
for having a datastore type API.
r the principle of least surprise.
From: Michael Basnight [mbasni...@gmail.com]
Sent: Monday, October 21, 2013 3:12 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore
type when creating an
What is the major motivation not to simply use a glance image named "MySQL
5.5" or "MongoDB 2.4"?
Wouldn't that give service providers all the flexibility they need for
providing different types? For example, I could offer a simple "MySQL"
image that creates a MySQL instance. If all my users use t
On Oct 18, 2013, at 12:30 PM, Tim Simpson wrote:
> 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:
I agree with this.
> 2. I also think a datastore_version alone should be sufficient since the
> as
e 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 De
, 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 ver
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 ty
tack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type
when creating an instance
Hi Tim,
I do think your recommendation in 3 & 4 makes a lot of sense and improves the
usability of the API. Given that Trove currently only supports a sing
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>"
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Trove] How users should specify a datastore type when
creating an instance
Hello fellow Trovians,
There has been some good work rec
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
deci
30 matches
Mail list logo
