I don't work on Sahara, but I do work on a similar closed-source project.
FWIW, I agree with Kevin here. standalone and pseudo-distributed HBase
are only intended for Hbase developers to test code without having to spin
up a cluster; it's not meant for operators or users to actually use as a
datab
I'm opinionated because I work with/on Taskflow and had mostly bad
experiences with Celery, but here's my $0.02. It's possible that the
codebase I inherited just made bad use of Celery or things have improved a
lot in the last 18 months, but all I can speak from is my own experience.
Taskflow and
Normally I reserve the begging for IRC, but since the other cores aren't always
on, I'm taking the shotgun approach. If you aren't a core on taskflow, then
you can safely skip the rest of this email.
We have a number of open reviews with a single +2 that need another core
reviewer to sign off.
I've been working on fixing a bug related to migrating existing installations
to the new datastore code:
https://bugs.launchpad.net/trove/+bug/1259642
The basic gist is that existing instances won't have any data in the
datastore_version_id field in the database unless we somehow populate that
ers
mailto:myer0...@gmail.com>> wrote:
There is the database migration for datastores. We should add a function to
back fill the existing data with either a dummy data or set it to 'mysql' as
that was the only possibility before data stores.
On Dec 18, 2013 3:23 PM, "Greg
am don't care about data integrity in our own product :)
Robert
On Thu, Dec 19, 2013 at 9:25 AM, Greg Hill
mailto:greg.h...@rackspace.com>> wrote:
We did consider doing that, but decided it wasn't really any different from the
other options as it required the deployer to know
+1
On Dec 27, 2013, at 4:48 PM, Michael Basnight
mailto:mbasni...@gmail.com>> wrote:
Howdy,
Im proposing Auston McReynolds (amcrn) to trove-core.
Auston has been working with trove for a while now. He is a great reviewer. He
is incredibly thorough, and has caught more than one critical error
I've begun working on the scheduled tasks feature that will allow automated
backups (and other things) in trove.
Here's the blueprint:
https://wiki.openstack.org/wiki/Trove/scheduled-tasks
I've heard some mention that mistral might be an option rather than building
something into trove. I did
I accidentally sent this reply to Josh directly.
Greg
On Dec 30, 2013, at 12:17 PM, Greg Hill
mailto:greg.h...@rackspace.com>> wrote:
Taskflow seems like it would be a good fit for implementation or
re-implementation of some of the tasks we hope to automate, but the first set
of d
I guess this isn't a new discussion. I did some more digging and apparently
this is what came out of the last discussion:
https://wiki.openstack.org/wiki/EventScheduler
That definitely seems like it would be something simple we could use, since it
only provides scheduling and that's all we nee
Renat,
Thanks for the additional information. I've been trying to put the pieces of
history together and it seems I missed some of it. I think I now understand
the evolution of things. Mistral does seem like it would work for what we
need, so I'll definitely be paying attention to it.
I'm c
I got a -1 on a review for a standards violation that isn't caught by the
automated checks, so I was wondering why the automated check doesn't catch it.
The violation was:
from X import Y, Z
According to the coding standards page on the openstack wiki, the coding
standards are PEP8 (they just
just loosen the coding standards, but that's just crazy talk :D
Greg
On Jan 7, 2014, at 8:46 AM, Sean Dague wrote:
> On 01/07/2014 09:26 AM, Greg Hill wrote:
>> I got a -1 on a review for a standards violation that isn't caught by
>> the automated checks, so I was w
So it turns out that trove just has this rule disabled. At least I now know
more about how this stuff works, I guess. Sorry for the confusion.
Greg
On Jan 7, 2014, at 9:54 AM, Sean Dague wrote:
> On 01/07/2014 10:19 AM, Greg Hill wrote:
>> Thanks Sean. I'll work on adding t
I'm not really an active nova contributor as of yet, but I'll +1 this if nova's
XML support is anything like what I see in trove (which I believe just cloned
how nova did it in the first place). XML without a schema is terrible for a
serialization format. In my experience, the only people who
If you're just using it for client-side templates, you should be able to treat
it like any other js library (jquery, etc) without using npm (node's package
manager) for installation. Handlebars, for example, has a single downloadable
js file that is available on their website:
http://builds.ha
Trove doesn't use ssh afaik. It has an agent that runs in the guest that is
communicated with via our normal RPC messaging options.
Greg
On Jan 13, 2014, at 11:10 AM, Doug Hellmann
mailto:doug.hellm...@dreamhost.com>> wrote:
On Mon, Jan 13, 2014 at 11:34 AM, Bhuvan Arumugam
mailto:bhu...@
Is there any project or proposed project for centralizing notifications from
openstack services to alert tenants when things go wrong (or right)? Say, for
example, a nova instance failed to finish the build process, and the customer
wants an email alert when that happens, or a trove database fa
Thanks. Is there any more detail about what that is going to look like and how
far along it might be?
Greg
On Jan 14, 2014, at 9:13 AM, Julien Danjou wrote:
> On Tue, Jan 14 2014, Greg Hill wrote:
>
>> Is there any project or proposed project for centralizing notifications from
Another +1 for option 3.
Greg
On Jan 22, 2014, at 2:27 PM, Denis Makogon
mailto:dmako...@mirantis.com>> wrote:
Goodday to all.
#3 looks more than acceptable.
/datastores//configuration/parameters.
According to configuration parameters design, a configuration set must be
associated to exactly
To be more consistent with other APIs in trove, perhaps:
/datastores//parameters
/datastores//parameters/
Greg
On Jan 22, 2014, at 4:52 PM, Kaleb Pomeroy
mailto:kaleb.pome...@rackspace.com>> wrote:
I think that may have been a slight oversite. We will likely have the following
two routes
/da
The blueprint is here:
https://wiki.openstack.org/wiki/Trove/scheduled-tasks
I've been working on the REST API portion of this project, and as I was working
on the client, a part of it didn't sit quite right. As it is specified, it
calls for two fields to define when and how often to run the t
On Jan 23, 2014, at 3:41 PM, Michael Basnight wrote:
>
> Will we be doing more complex things than "every day at some time"? ie, does
> the user base see value in configuring backups every 12th day of every other
> month? I think this is easy to write the schedule code, but i fear that it
>
I'm new, so I'm sure there's some history I'm missing, but I find it bizarre
that we have to put the same license into every single file of source code in
our projects. In my past experience, a single LICENSE file at the root-level
of the project has been sufficient to declare the license chose
I've been out of the openstack loop for a few years, so I hope this reaches
the right folks.
Josh Harlow (original author of taskflow and related libraries) and I have
been discussing the option of moving taskflow out of the openstack umbrella
recently. This move would likely also include the futu
> I'm not sure how using pull requests instead of Gerrit changesets would
> help "core reviewers being pulled on to other projects"?
>
The 2 +2 requirement works for larger projects with a lot of contributors.
When you have only 3 regular contributors and 1 of them gets pulled on to a
project and
26 matches
Mail list logo
