> 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
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
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
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
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
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
On Jan 23, 2014, at 3:41 PM, Michael Basnight mbasni...@gmail.com 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
To be more consistent with other APIs in trove, perhaps:
/datastores/datastore/parameters
/datastores/datastore/parameters/parameters
Greg
On Jan 22, 2014, at 4:52 PM, Kaleb Pomeroy
kaleb.pome...@rackspace.commailto:kaleb.pome...@rackspace.com wrote:
I think that may have been a slight
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
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
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 jul...@danjou.info wrote:
On Tue, Jan 14 2014, Greg Hill wrote:
Is there any project or proposed project for centralizing notifications
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:
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
doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote:
On Mon, Jan 13, 2014 at 11:34 AM,
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
the coding standards, but that's just crazy talk :D
Greg
On Jan 7, 2014, at 8:46 AM, Sean Dague s...@dague.net 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 wondering why the automated check
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 s...@dague.net wrote:
On 01/07/2014 10:19 AM, Greg Hill wrote:
Thanks Sean. I'll work on adding
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
+1
On Dec 27, 2013, at 4:48 PM, Michael Basnight
mbasni...@gmail.commailto: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
I accidentally sent this reply to Josh directly.
Greg
On Dec 30, 2013, at 12:17 PM, Greg Hill
greg.h...@rackspace.commailto: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
...@gmail.commailto: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 Hill
greg.h
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
22 matches
Mail list logo
