Re: Soliciting feature requests for 0.8.0

It might be a first step towards that, but I don't think the currently scoped authentication work includes limiting read access via the UI. On Thu, Feb 19, 2015 at 2:22 PM, Erb, Stephan wrote: > We would be interested in the Shiro authentication track as well. > > As I understand it, is a prereq

Re: [VOTE] Graduate Apache Aurora as a TLP

listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache Aurora Project: > >* Mark Chu-Carroll >* William Farner >* Jake Farrell >* Benjamin Hindman >* Suman Karumuri >* Maxim Khutornenko >* Dave Lester

Re: Feature proposal: ability to apply a block on all updates in the scheduler

Ah, that's what I was looking for. Thanks! On Wed, Feb 11, 2015 at 11:54 AM, Maxim Khutornenko wrote: > +1 to the proposal. However, the ticket already exists: > https://issues.apache.org/jira/browse/AURORA-1091. > > On Wed, Feb 11, 2015 at 11:51 AM, David McLaughlin > wrot

Feature proposal: ability to apply a block on all updates in the scheduler

Hi aurora-dev, I'd like to propose a feature that I think could be useful to admins/operators of Aurora clusters. The feature would be to allow an administrator of the cluster to "block" write operations from happening in the scheduler, essentially putting it into read-only mode for a period of ti

Re: Heartbeat mechanism auditing

> overlooked details may hurt down the road by requiring Thrift schema > migration. > Thanks, > Maxim > > [1] - > http://mail-archives.apache.org/mod_mbox/incubator-aurora-dev/201410.mbox/browser > > On Thu, Jan 29, 2015 at 2:07 PM, David McLaughlin > wrote: > &

Heartbeat mechanism auditing

Hi all, There is a little bit of a stalemate with regards to the implementation of the pulse RPC in the scheduler. As a brief overview of this feature - the pulse RPC is designed so that an external service can monitor the new in-scheduler updates reliably. This external service could be doing so

Re: Coordinated update configuration

The heartbeat requirement feature should be disabled by default, so I think it's best to just do [1] and make it None by default in UpdateConfig and optional field in the thrift API. On Tue, Jan 27, 2015 at 10:21 AM, Maxim Khutornenko wrote: > We are working on AURORA-690 to support external ser

Re: [DISCUSS] Deprecate use of mock.patch?

I'm -1 to blanket scrubbing of legitimately useful testing techniques like mock.patch. I find mock.patch a lot cleaner than polluting the interface with every function the code under test might need to call. I'm definitely +1 to not mocking things deeper than 1 in the stack. It's one of the strang

Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

+1 All tests pass. On Mon, Nov 17, 2014 at 3:47 PM, Joshua Cohen wrote: > Oh, forgot to add: > > +0: I had to bump memory for Vagrant image to 2 gigs. But no one else seems > to be having this problem. > > On Mon, Nov 17, 2014 at 3:45 PM, Joshua Cohen > wrote: > > > +1 > > > > signature looks

Re: Build failed in Jenkins: Aurora #731

ortunately the number is not consistent. > > -=Bill > > On Wed, Nov 12, 2014 at 3:37 PM, David McLaughlin > wrote: > > > Am I reading this wrong or does that say that the actual coverage of 0.84 > > exceeds the _minimum_ coverage and this led to the build failure?

Re: Build failed in Jenkins: Aurora #731

Am I reading this wrong or does that say that the actual coverage of 0.84 exceeds the _minimum_ coverage and this led to the build failure? On Wed, Nov 12, 2014 at 3:34 PM, Joshua Cohen wrote: > Failing the build on this check is just too flaky (coverage numbers vary > slightly based on JVM). Go

Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC1

+1 from me +1 java unit tests pass +1 python unit tests pass +1 e2e tests pass +0 had a transient failure in e2e tests On Wed, Nov 12, 2014 at 2:02 PM, Bill Farner wrote: > Reminder - the vote closes in ~24 hours. We currently lack enough votes > for a release. Please chime in, folks! > > -=B

Re: Proposal: External Update Coordination

+1 for pause being explicit RPC pauses, but does it really add complexity to just add a new state (WAITING?) when no heartbeat is sent? Not being able to see that an update was blocked because of a lack of heartbeat seems like a missing feature. On Wed, Oct 15, 2014 at 5:12 PM, Maxim Khutornenko

Re: Proposal: External Update Coordination

- A heartbeatJobUpdate RPC is called with the matching update ID. Scheduler resets countdown and responds with STOP Paused is a tricky state because the user can resume at any time. I'd propose we have a different response here. You really don't want to "stop" monitoring the update while it

Re: Build failed in Jenkins: Aurora #618

It's unrelated to the commit I pushed (a python change). ./gradlew -Pq build also works locally. On Mon, Oct 6, 2014 at 11:42 AM, Zameer Manji wrote: > Is anyone on this? > > On Mon, Oct 6, 2014 at 11:28 AM, Apache Jenkins Server < > jenk...@builds.apache.org> wrote: > > > See

Re: Error handling in the aurora client

Because we allow things like hooks, I think it's best to err on the side of overly verbose logging by default rather than have to ask client users to rerun their command with an extra option just to get a stack trace. On Thu, Oct 2, 2014 at 1:10 PM, Mark Chu-Carroll wrote: > Can someone explain

Re: Error handling in the aurora client

+1 to everything Kevin said. On Thu, Oct 2, 2014 at 12:51 PM, Kevin Sweeney wrote: > We can do both! I think we should dump a stack trace to the console > whenever we have an unhandled error, as we're not going to be able to debug > it otherwise. > > We should also strive not to have *any* unhan

Re: Proposal: remove v1 client as part of 0.6.0 release

+1 to complete removal. The plan to phase out the client also sounds good to me. On Wed, Oct 1, 2014 at 3:38 PM, Kevin Sweeney wrote: > +1 to complete removal > > On Wed, Oct 1, 2014 at 3:26 PM, Bill Farner wrote: > > > I've just created AURORA-775 [1] to track removal of the v1 client build,

Re: Build failed in Jenkins: Aurora #562

Is this a known issue with the python tests? My commit today only changed JavaScript, CSS and HTML. On Tue, Sep 16, 2014 at 1:46 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [dmclaughlin] Add update informa

Re: Suggested update to the Aurora homepage

+1 On Wed, Sep 10, 2014 at 2:38 PM, Kevin Sweeney wrote: > +1 > > On Wed, Sep 10, 2014 at 2:30 PM, Bill Farner wrote: > > > +1 > > > > -=Bill > > > > > > On Wed, Sep 10, 2014 at 10:54 AM, Dave Lester > wrote: > > > > > Works for me; I'd suggest embedding the video starting 43 seconds in: > > >

Re: one lock to lock them all

Hi Isaac, That behaviour is definitely not intentional. This sounds like it was the bug with an incorrect JOIN type in SQL. The ticket tracking that issue is here: https://issues.apache.org/jira/browse/AURORA-640 I'm not sure though if the fix made it in in time for that release. - David On

Re: Proposal: API changes to getTasksStatus

tasks by not supplying an offset or limit to their query. If you drop information from the response however, now the client can't do that at all. > > On Wed, May 28, 2014 at 4:42 AM, Mark Chu-Carroll > wrote: > > > Great. +1 from me. > > > > > > On Tue, May

Re: Updated proposal: Aurora Shorthands

in fact, all of the bracket characters already are > used. For single-character prefixes, there aren't many characters that > aren't already used by the shell - we can't use !, #, $, ^, &, *, ~, or ?. > For easy to type stuff, that left very little other than @. And @ i

Re: Proposal: API changes to getTasksStatus

returns to a command implementation. It'll definitely > complicate things to add pagination. How much of an effect will it be? > > -Mark > > > > On Tue, May 27, 2014 at 5:32 PM, David McLaughlin >wrote: > > > As outlined in AURORA-458, using the new jobs

Re: Updated proposal: Aurora Shorthands

I am a huge +1 on the idea of storing my run configurations in config files so that I don't need to type them out every time. I also really like the idea of command defaults. I do however have a couple of comments about the details of the proposal. I'm a little concerned about the fallback to the

Proposal: API changes to getTasksStatus

As outlined in AURORA-458, using the new jobs page with a large (but reasonable) number of active and complete tasks can take a long time[1] to render. Performance profiling done as part of AURORA-471 shows that the main factor in response time is rendering and returning the size of the uncompresse

Re: Adding shorthands, defaults, and initialization files to the aurora client

On Mon, May 19, 2014 at 8:44 AM, Mark Chu-Carroll wrote: > Folks: > > Now that clientv2 is approaching stability, I'd like to start making some > usability changes. These are completely backwards compatible, but they're > intended to make the most common ways of using the aurora client more > conv