+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-
> Fro
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:
https://github.com/openstack/trove/commit/06196fcf67b27f0308381da192da5cc8ae65b157#diff-a4d09d28bd2b650c2327f5d8d81be3a9
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 ag
>> 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 fr
based on API project needs.
I hope that covers your concerns.
Dmitry
2013/12/18 Tim Simpson
mailto: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 existi
and how it's written and explained, has changed a lot over the past ten years.
Thanks,
Tim
-Original Message-
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: [openst
>> 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 t
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
tting conductor deal with it ?
Best regards,
Denis Makogon
2013/12/20 Tim Simpson
mailto: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 be dealt with.
&
service.py
There are no checks for datastore_type, service just loads root model and
that's it, since my patch create root model, next API call (root check) will
load this model.
2013/12/20 Tim Simpson
mailto:tim.simp...@rackspace.com>>
Because the ability to check if root is enabled
nce my patch create root model, next API call (root check) will
load this model.
2013/12/20 Tim Simpson
mailto: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 woul
>> 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,
+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 proposin
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
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 manage
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 wai
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 drive
M
To: OpenStack 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 wrote:
On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson wrote:
Hi fellow Trove devs,
Wit
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
le
datastore deployment per control 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 mailto:tim.simp...@rackspace.com>>
Reply
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
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 cou
;s changes arrive soon.
>
> Best wishes.
>
>
>
> On Mon, Oct 21, 2013 at 7:01 PM, Tim Simpson
> 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 hopeful
ve] Testing of new service types support
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.
>
&g
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
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
> 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 i
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
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
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 inc
, 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 vers
.
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 (g
35 matches
Mail list logo
