+1
From: Sergey Gotliv [sgot...@redhat.com]
Sent: Tuesday, August 26, 2014 8:11 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core
Strong +1 from me!
-Original Message-
Hi everyone,
I was looking through the clustering code today and noticed a lot of it is
grabbing what I'd call the guts of the instance models code.
The best example is here:
I've been following the Unified Agent mailing list thread for awhile now and,
as someone who has written a fair amount of code for both of the two existing
Trove agents, thought I should give my opinion about it. I like the idea of a
unified agent, but believe that forcing Trove to adopt this
Please provide proof of that assumption or at least a general hypothesis
that we can test.
I can't prove that the new agent will be larger as it doesn't exist yet.
Since nothing was agreed upon anyway, I don't know how you came to that
conclusion. I would suggest that any agent framework
on API project needs.
I hope that covers your concerns.
Dmitry
2013/12/18 Tim Simpson
tim.simp...@rackspace.commailto:tim.simp...@rackspace.com
I've been following the Unified Agent mailing list thread for awhile now and,
as someone who has written a fair amount of code for both of the two
-
From: Steven Dake [mailto:sd...@redhat.com]
Sent: Wednesday, December 18, 2013 4:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent
On 12/18/2013 12:27 PM, Tim Simpson wrote:
Please provide proof
I agree that enabling communication between guest and cloud service is a
common problem for most agent designs. The only exception is agent based on
hypervisor provided transport. But as far as I understand many people are
interested in network-based agent, so indeed we can start a thread
I second Rob and Greg- we need to not allow the instance table to have nulls
for the datastore version ID. I can't imagine that as Trove grows and evolves,
that edge case is something we'll always remember to code and test for, so
let's cauterize things now by no longer allowing it at all.
The
Hi Denis,
The plan from the start with Conductor has been to remove any guest connections
to the database. So any lingering ones are omissions which should be dealt with.
Since not each database have root entity (not even ACL at all) it would be
incorrect to report about root enabling on
) will
load this model.
2013/12/20 Tim Simpson
tim.simp...@rackspace.commailto:tim.simp...@rackspace.com
Because the ability to check if root is enabled is in an extension which would
not be in effect for a datastore with no ACL support, the user would not be
able to see that the marker for root
Would it make more sense for an operator to configure a time window, and
then let users choose a slot within a time window (and say there are a
finite number of slots in a time window). The slotting would be done behind
the scenes and a user would only be able to select a window, and if
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
system, does the current work also allow for a
default type/version to be defined so that operators of Trove can set this as a
property to maintain the current API compatibility/behavior?
Josh
From: Tim Simpson tim.simp...@rackspace.commailto:tim.simp...@rackspace.com
Reply-To: OpenStack
: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
Hi Illia,
You're correct; until the work on establishing datastore types and versions as
a first class Trove concept is finished, which will hopefully be soon (see
Andrey Shestakov's pull request), testing non-MySQL datastore types will be
problematic.
A short term, fake-mode only solution
.
On Mon, Oct 21, 2013 at 7:01 PM, Tim Simpson tim.simp...@rackspace.com
wrote:
Hi Illia,
You're correct; until the work on establishing datastore types and versions
as a first class Trove concept is finished, which will hopefully be soon (see
Andrey Shestakov's pull request), testing non
On Oct 21, 2013, at 10:02 AM, Tim Simpson wrote:
Can't we say that about nearly any feature though? In theory we could put a
hold on any tests for feature work saying it
will need to be redone when Tempest integrated is finished.
Keep in mind what I'm suggesting here is a fairly trivial
]
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
This is also true that we dont want to define the _need_ to have custom
images for the datastores. You can, quite easily, deploy mysql or redis on a
vanilla image.
Additionally there could be server code at some point soon that will need to
know what datastore type is associated with an
] [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
So if we decide to support any number of config options for each various
datastore version, eventually we'll have large config files that will be hard
to manage.
What about storing the extra config info for each datastore version in its own
independent config file? So rather than having one
.
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
To summarize, this is a conversation about the following LaunchPad bug:
https://launchpad.net/bugs/1325512
and Gerrit review: https://review.openstack.org/#/c/97194/6
You are saying the function _service_is_active in addition to polling the
datastore service status also polls the status of the
I agree as well.
I think we should spend less time worrying about what other projects in
OpenStack might do in the future and spend more time on adding the features we
need today to Trove. I understand that it's better to work together but too
often we stop progress on something in Trove to
+1
From: Peter Stachowski [pe...@tesora.com]
Sent: Tuesday, May 06, 2014 9:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Trove] Proposal to add Craig Vyvial to trove-core
+1
-Original Message-
+1
From: Nikhil Manchanda [nik...@manchanda.me]
Sent: Thursday, October 30, 2014 3:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
Hello folks:
I'm
Hi Denis,
It seems like the issue you're trying to solve is that these 'prepare' messages
can't be consumed by the guest.
So, if the guest never actually comes online and therefore can't consume the
prepare call, then you'll be left with the message in the queue forever.
If you use a ping-pong
Development Mailing List
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate
integration.
On Oct 1, 2013, at 3:06 PM, Ilya Sviridov isviri...@mirantis.com wrote:
On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson tim.simp...@rackspace.com wrote
as involved.
For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson
29 matches
Mail list logo
