*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
, 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
:* 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
datastore type when creating an instance
Small suggestion on listing datastore_type:
Since all
*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
*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
] [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
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
-
: 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 datasource
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:* Re: [openstack-dev] [Trove] How users should
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
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 configuration
]
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_version alone should be sufficient
.
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, Nikhil Manchanda wrote
] [Trove] How users should specify a datastore type
when creating an instance
On Mon, Oct 21, 2013 at 2:04 PM, Michael Basnight
mbasni...@gmail.commailto:mbasni...@gmail.com wrote:
On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote:
2. I also think a datastore_version alone should be sufficient since
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 them
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
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
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
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 the
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.
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 default (or
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
On Mon, Oct 21, 2013 at 11:40 PM, Tim Simpson tim.simp...@rackspace.com 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
On Mon, Oct 21, 2013 at 2:04 PM, Michael Basnight mbasni...@gmail.comwrote:
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
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
: Friday, October 18, 2013 2:30 PM
To:
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Trove] How users should specify a datastore type when
creating an instance
Hello fellow
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 single
datastore deployment per control
27 matches
Mail list logo
