Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core

2014-08-26 Thread Tim Simpson
+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-

[openstack-dev] [Trove] Cluster implementation is grabbing instance's gutsHi guys, I was looking through the clustering code today and noticed a lot of it is grabbing what I'd call the guts of the ins

2014-09-11 Thread Tim Simpson
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:

[openstack-dev] [trove] My thoughts on the Unified Guest Agent

2013-12-18 Thread Tim Simpson
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

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

2013-12-18 Thread Tim Simpson
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

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

2013-12-18 Thread Tim Simpson
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

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

2013-12-18 Thread Tim Simpson
- 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

Re: [openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified Agents - what is the actual problem?

2013-12-19 Thread Tim Simpson
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

Re: [openstack-dev] [trove] datastore migration issues

2013-12-19 Thread Tim Simpson
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

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

2013-12-20 Thread Tim Simpson
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

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

2013-12-20 Thread Tim Simpson
conductor deal with it ? Best regards, Denis Makogon 2013/12/20 Tim Simpson tim.simp...@rackspace.commailto:tim.simp...@rackspace.com 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

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

2013-12-20 Thread Tim Simpson
) 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

Re: [openstack-dev] [trove] scheduled tasks redux

2014-01-24 Thread Tim Simpson
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

[openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-18 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-18 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-21 Thread Tim Simpson
: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

Re: [openstack-dev] [Trove] Testing of new service types support

2013-10-21 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] Testing of new service types support

2013-10-21 Thread Tim Simpson
. 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

Re: [openstack-dev] [Trove] Testing of new service types support

2013-10-21 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-21 Thread Tim Simpson
To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance 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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-22 Thread Tim Simpson
] 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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-22 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-22 Thread Tim Simpson
] 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 tim.simp...@rackspace.com wrote: 4. Additionally, in the current

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-22 Thread Tim Simpson
] [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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-24 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

2013-10-28 Thread Tim Simpson
. 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

Re: [openstack-dev] [trove] guestagent config for overriding managers

2014-07-02 Thread Tim Simpson
I’m a fan of the later suggestion. Thanks, Tim From: Craig Vyvial [mailto:cp16...@gmail.com] Sent: Tuesday, July 01, 2014 11:35 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [trove] guestagent config for overriding managers If you want to override the trove guestagent

Re: [openstack-dev] [Trove] Guest prepare call polling mechanism issue

2014-07-23 Thread Tim Simpson
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

Re: [openstack-dev] [Glance][Trove] Metadata Catalog

2014-07-24 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] Proposal to add Craig Vyvial to trove-core

2014-05-06 Thread Tim Simpson
+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-

Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core

2014-10-30 Thread Tim Simpson
+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

Re: [openstack-dev] [Trove] Guest RPC API improvements. Messages, topics, queues, consumption.

2014-10-31 Thread Tim Simpson
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

[openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.

2013-10-01 Thread Tim Simpson
Hi fellow Trove devs, With the Designate project ramping up, its time to refactor the ancient DNS code that's in Trove to work with Designate. The good news is since the beginning, it has been possible to add new drivers for DNS in order to use different services. Right now we only have a

Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.

2013-10-01 Thread Tim Simpson
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

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Tim Simpson
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