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

+1 from me. Downloaded, built, and ran tests. On Wed, Jan 28, 2015 at 3:22 PM, Joshua Cohen wrote: > +1 md5 matches, signature is valid, java, python and end to end tests all > pass. > > On Wed, Jan 28, 2015 at 11:18 AM, Zameer Manji wrote: > > > +1 Release this as Apache Aurora 0.7.0 > > > >

Re: AURORA-507

The missing detail is that MyBatis dynamically creates an implementation of LockMapper based on LockMapper.xml [1]. However, i'm now realizing that this should probably not be classified as a newbie ticket, since the the plumbing goes pretty deep, and knowledge of several technologies is necessary

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

Hash file looks good. Signature is good. Tests pass. DISCLAIMER and LICENSE files look good. No 3rd party executables. Small detail -1 because NOTICE file need to be updated to Copyright 2014-2015. I would think some IPMC members will cry foul. If JIRA is file against NOTICE file then +1 from me.

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

Thanks for catching this Henry! Created AURORA-1072 and added it as a 0.8.0 release blocker. On Thu, Jan 29, 2015 at 11:52 AM, Henry Saputra wrote: > Hash file looks good. > Signature is good. > Tests pass. > DISCLAIMER and LICENSE files look good. > No 3rd party executables. > > Small detail -1

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

Thanks Maxim, Change to +1 (binding) - Henry On Thu, Jan 29, 2015 at 12:29 PM, Maxim Khutornenko wrote: > Thanks for catching this Henry! Created AURORA-1072 and added it as a > 0.8.0 release blocker. > > On Thu, Jan 29, 2015 at 11:52 AM, Henry Saputra > wrote: >> Hash file looks good. >> Sig

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: Heartbeat mechanism auditing

To add a bit of history to the topic, the current design has been debated heavily here [1] and an active/lazy consensus was reached around implementing the first iteration as lightweight as possible without persisting any durable state. My take on this - we should proceed as originally proposed gi

Re: Heartbeat mechanism auditing

Here's the permalink to the thread in question: http://mail-archives.apache.org/mod_mbox/incubator-aurora-dev/201410.mbox/%3CCAOTkfX7x2oipk4ZFysoS0uWZRizOnKJA3y15pvEW5K4YnUHw-A%40mail.gmail.com%3E -=Bill On Thu, Jan 29, 2015 at 2:45 PM, Maxim Khutornenko wrote: > To add a bit of history to the

Re: Heartbeat mechanism auditing

Here's the permalink to the thread in question: http://mail-archives.apache.org/mod_mbox/incubator-aurora-dev/201410.mbox/%3CCAOTkfX7x2oipk4ZFysoS0uWZRizOnKJA3y15pvEW5K4YnUHw-A%40mail.gmail.com%3E -=Bill On Thu, Jan 29, 2015 at 2:45 PM, Maxim Khutornenko wrote: > To add a bit of history to the

Re: Heartbeat mechanism auditing

I'm actually beginning to think that an explicit state for "waiting for a heartbeat" might be easier to implement than volatile state. In a world where job updates are fully automated, i could see a bunch of users asking why a job update made no progress for a period of time, so it's really nice i

Re: Heartbeat mechanism auditing

+1, the implementation tradeoffs were discussed extensively in that thread. Regarding the potential user experience my thought is that http://mail-archives.apache.org/mod_mbox/incubator-aurora-dev/201410.mbox/%3CCAAATh-bA0f4yPAoH8+xrwd=xkzhgqvm8nylle6ihha-hdes...@mail.gmail.com%3E presents an acc

Re: Heartbeat mechanism auditing

On Thu, Jan 29, 2015 at 2:45 PM, Maxim Khutornenko wrote: > To add a bit of history to the topic, the current design has been > debated heavily here [1] and an active/lazy consensus was reached > around implementing the first iteration as lightweight as possible > without persisting any durable s

Re: AURORA-507

Hmm, I'm happy to look at AURORA-189 first, but I'd still like to keep working on 507 if possible. From reading up on MyBatis, it does not look to be very complicated. Does all persistent lock state end up in the DbLockStore eventually ? i.e does WriteAheadStorage call DbLockStore internally (thro

Working on AURORA-189

Hi, I'd like to start working on AURORA-189 and any ideas or help is welcome. Looking at the code it looks like LoggingInterceptor.java