Re: Attempting to Push Aurora to ~11 requests/second

33 AM, Ryan Orr wrote: > https://gist.github.com/ryanorr/b3736c03a9919f9b87dc > > Just a simple bash script. I run 10-15 of them in the background and it > crashes usually in less than 30 mins as described. Thanks for looking into > it. > > On Wed, Mar 18, 2015 at 7:19 PM, Bil

Re: Attempting to Push Aurora to ~11 requests/second

I'm slightly doubtful that GC is the issue (based on background from Ryan in IRC), but i could be wrong. Trying out a sample script would help us confirm or deny, though. -=Bill On Wed, Mar 18, 2015 at 11:17 AM, Maxim Khutornenko wrote: > This time gap of over 2 seconds suggests there may have

Re: Apache Aurora Graduation

Hear, hear! Thanks so much to everyone for your support, we have had an impressive cast of important characters on the road so far. I'm really looking forward to seeing where this project goes! -=Bill On Wed, Mar 18, 2015 at 12:01 PM, Jake Farrell wrote: > Today the Apache board approved the

Re: Attempting to Push Aurora to ~11 requests/second

If you can provide a script to trigger this in the vagrant environment it will be a tremendous help in finding the cause. On Wednesday, March 18, 2015, Ryan Orr wrote: > We're attempting to get Aurora to handle 11 job requests a second. We > realize we're going to be limited by the resource inte

Re: Speeding up Aurora client job creation

lues? > > > > > > Hussein Elgridly > > Senior Software Engineer, DSDE > > The Broad Institute of MIT and Harvard > > > > > > On 12 February 2015 at 04:15, Erb, Stephan > > wrote: > > > > > Hi Hussein, > > > > > > we also had slight performance problems when talkin

Re: Build failed in Jenkins: Aurora #942

Known flaky test. https://issues.apache.org/jira/browse/AURORA-1162 -=Bill On Mon, Mar 16, 2015 at 7:46 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [wfarner] Rename beta-update subcommand to update. > > -

Heads up - please destroy and re-create your vagrant environment

I just committed a change that alters the scheduler command line arguments in the upstart configuration. Due to the way vagrant provisioning currently works, this means the now-removed argument will be unrecognized by new scheduler builds. Please use vagrant destroy to nuke this old environment.

Re: Problem getting docker container running

When the task launches, a sandbox directory is created, in the above e-mail it was /tmp/mesos/slaves/20150313-131712-1143806393-5050-6-S0/frameworks/20150306-112428-1177360825-5050-6-/executors/thermos-1426253925515-docker-test-devel-hello_docker-0-a9011a74-c2a2-4cb7-b402-d383fde58c41/runs/e53

Re: installing Aurora client fails

Thanks, John! -=Bill On Wed, Mar 11, 2015 at 3:16 PM, John Sirois wrote: > On Wed, Mar 11, 2015 at 2:55 PM, Andras Kerekes < > andras.kere...@ishisystems.com> wrote: > > > Hi All, > > > > > > > > I’m trying to install the Aurora CLI client and no success. I’m on Ubuntu > > 12.04 running in Virt

Re: installing Aurora client fails

to > the root of the Git repo. > > Hussein Elgridly > Senior Software Engineer, DSDE > The Broad Institute of MIT and Harvard > > > On 11 March 2015 at 17:43, Bill Farner wrote: > > > This isn't a solution, but are you able to try to repro in a 14.04 image?

Re: Data processing pipeline workflow management

I'm afraid in general the use cases you describe are not things that Aurora currently intends to fulfill. Though, that's not to say that you could not do this on top of Aurora if you wanted to. Does anyone have experience with building workflows with Aurora? I do not. I could opine about how o

Re: new features

On Tue, Mar 10, 2015 at 6:39 AM, Haralds Ulmanis wrote: > Hello, did not find where yo open such discussion about features, but after > working with aurora here is few ideas: > 1. not pre-defined instance count. > Currently you need to specify exact number of instances on which you want > to run

Re: installing Aurora client fails

This isn't a solution, but are you able to try to repro in a 14.04 image? This is the environment we are currently qualifying development against, so a failure there might generate more data for us. -=Bill On Wed, Mar 11, 2015 at 1:55 PM, Andras Kerekes < andras.kere...@ishisystems.com> wrote: >

Re: Custom executor support

The client offers no support for this currently, but the scheduler will work fine - it is ignorant of executors. So, while you would need to roll up your sleeves, you shouldn't need to move a mountain to get this working. -=Bill On Wed, Mar 11, 2015 at 9:57 AM, Soni,Mohit wrote: > I would like

Re: Build failed in Jenkins: Aurora #929

Known flaky test: https://issues.apache.org/jira/browse/AURORA-1054 -=Bill On Tue, Mar 10, 2015 at 6:01 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [zmanji] Improve response logging in TRequestsTransport

Re: Insufficient resource quota when production is True

This is, unfortunately, only sparsely documented [1]: Whether or not this is a production task backed by quota (Default: False). > Production jobs may preempt any non-production job, and may only be > preempted by production jobs in the same role and of higher priority. To > run jobs at this level

Re: [RESULT][VOTE] Graduate Apache Aurora from the Incubator

elow 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

Re: Shepherding new contributions

Thanks for that background, Henry! That is actually useful for other unrelated thoughts I have had. We will make sure to keep this in mind. On Monday, February 23, 2015, Henry Saputra wrote: > Ok, we need to be careful about this maintainers/owners or shepherds > business. > > Apache Spark got

Re: [proposal] Deprecate the Thermos CLI

s: > >1. Checking what Aurora has scheduled on the machine. >2. Checking the state of Thermos run processes. > > #1 Should be provided by Mesos and we should be keeping the CLI because of > #2. > > > > On Mon, Feb 23, 2015 at 3:54 PM, Bill Farner wrote: > &

Re: [proposal] Deprecate the Thermos CLI

how that follows. > > > > Are you saying that if Aurora can start scheduling Hadoop containers, > > people can't count on their Hadoop tools for debugging? > > > > On Mon, Feb 23, 2015 at 2:02 PM, Bill Farner wrote: > > > > > Perhaps i was uncle

Re: Shepherding new contributions

+1 to the idea. A first step in the right direction might be to do something you (unintentionally?) implied - default People. We could do this in .reviewboardrc [1], and let the people in there serve as dispatchers to find the right reviewers. I'm happy to volunteer to be in that list if that so

Re: [proposal] Deprecate the Thermos CLI

s status --verbosity=3" gives full thermos task history > > including the sandbox path and process table contents. This really > > saves time when trying to get to the failed task details or see what > > else is running on a host. > > > > On Wed, Feb 18, 2015

Re: Testing Done in RB?

I'm generally -1 to requiring humans to perform (what i perceive to be) superfluous redundant tasks. In this case, the standard suite of tests should be expected as part of any patch affecting code, which is why the review bot runs them. For that reason, i've mostly been using 'Testing done' to r

Re: Making sense of Aurora terminal states

explicit as it could be. I know I'd have had an easier time if > >> there had been an explanation of "here's what each state means and what > >> might happen next", and I can imagine [weasel words; citation needed] > that > >> other users might al

Re: RFC HealthCheck

; > n: set criteria > > } > > union HealthCheck { > 1: TcpCheck tcp > 2: HttpCheck http > } > > > We could obviously get pretty complicated with this if we choose to, but > starting with some opinionated defaults and an extensible structure may be > key. >

Re: RFC HealthCheck

some opinionated defaults and an extensible structure may be key. I also agree that graceful teardown should be decoupled from health checks. -=Bill On Sat, Feb 21, 2015 at 10:35 AM, Bill Farner wrote: > If i'm reading the code correctly, the only way to use mesos' health > check

Re: RFC HealthCheck

If i'm reading the code correctly, the only way to use mesos' health checks is with the command executor? Can somebody check my work on that? Some other context around health checks to keep in mind: - there is a review [1] in-flight for the executor to delay the transition to RUNNING until the fi

Heads up - breaking changes coming to API backing beta-update

Hi folks, As part of AURORA-1093 [1], i will be breaking backwards compatibility on the thrift API that backs the beta-update command. This is part of the contract that we hope to communicate by tagging features as beta - they are subject to change swiftly. *What this means for you* If you do no

Re: Making sense of Aurora terminal states

On Thu, Feb 19, 2015 at 1:27 PM, Hussein Elgridly < huss...@broadinstitute.org> wrote: > I've just spent the afternoon making a flowchart out of > TaskStateMachine.java in an attempt to figure out what Aurora states > actually mean. Given that all the jobs I submit have unique names and I > don't

Soliciting feature requests for 0.8.0

Hi Folks, I'd like to get the ball rolling on 0.8.0 by seeking input from the community about what you all would like to see in the next release. Bear in mind that we are aiming to release about once per month, so that duration should help guide the number and complexity of features we target. W

Re: [VOTE] Graduate Apache Aurora as a TLP

+1 Also, to clarify - Bill Farner and William Farner are the same person (me). -=Bill On Wed, Feb 18, 2015 at 5:36 PM, Zameer Manji wrote: > +1 > > On Wed, Feb 18, 2015 at 5:31 PM, David McLaughlin > wrote: > > > +1! > > > > On Wed, Feb 18, 2015

Re: [proposal] Deprecate the Thermos CLI

> Running "thermos status --verbosity=3" gives full thermos task history > including the sandbox path and process table contents. This really > saves time when trying to get to the failed task details or see what > else is running on a host. > > On Wed, Feb 18, 2015 at 12:04

Re: Getting secure data into Docker containers

Mounts is the most lo fi approach that comes to mind. I'd be in support of patches to satisfy (part of) AURORA-1107 to fulfill this need (which would hopefully be distinct from another perspective on AURORA-1107 in which end-users of Aurora can request arbitrary mounts). -=Bill On Wed, Feb 18, 2

Re: [proposal] Deprecate the Thermos CLI

> Moving parts should either provide value or be obliterated from our > > source tree. > > > > I generally agree. In this particular case it's still unclear to me - > > in the absence of Thermos CLI and Observer, how do we conduct live > > site executor/thermos troublesho

Re: Aurora.pex client can't find scheduler

s manually and > the example goes fine. Many thanks! > > On Wed, Feb 18, 2015 at 6:19 PM, Bill Farner > wrote: > > > The executor is dying, and the scheduler is defensively backing off from > > the task. Key s

Re: Ubuntu 12.04 - ImportError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.16' not found

Thanks for reporting back! I was a bit dumbfounded at what could be the issue. Now I know to rule out stale build state next time! On Wednesday, February 18, 2015, Larry Weya wrote: > I got it to work by doing a git clean within the repository and > re-building. > > I'm not too familiar with p

Re: Aurora.pex client can't find scheduler

The executor is dying, and the scheduler is defensively backing off from the task. Key scheduler log content is: I0218 14:26:57.759 THREAD156 org.apache.aurora.scheduler.mesos.MesosSchedulerImpl.statusUpdate: Received status update for task 1424269615751-weblab-devel-hello_server-0-d3181d51-669d-

Re: [proposal] Deprecate the Thermos CLI

> > I think we would be better served by advertising it as an > optional component that provides operators and users with debugging > ability. Slightly tangential discussion, but i think we should be very skeptical of fringe components. Moving parts should either provide value or be obliterated

Re: Rescheduling Monday's IRC meeting to Tuesday, Feb 17th

+1 to both suggestions -=Bill On Sun, Feb 15, 2015 at 3:37 PM, Dave Lester wrote: > Hi All, > > Since tomorrow is a federal holiday in the United States and a number of > folks will be taking some time off, I recommend rescheduling tomorrow's > weekly IRC meeting to Tuesday at 11AM Pacific. Wha

Re: Speeding up Aurora client job creation

To reduce that time you will indeed want to talk directly to the scheduler. This will definitely require you to roll up your sleeves a bit and set up a thrift client to our api (based on api.thrift [1]), since you will need to specify your tasks in a format that the thermos executor can understand

Re: Draft blog post for Aurora 0.7.0-incubating release

Thanks, Dave! On Wednesday, February 11, 2015, Dave Lester wrote: > Just to communicate this widely, the blog post and update has been > delayed slightly until *Thursday AM*, but will go online at that time. > t3hsteve will also have a blog post at that time and I'm working on one > of my own. I

Re: Seeking volunteers to create scheduler REST API RFC

o go over a http 2.0 end point? > > ~ Joestein > > On Mon, Feb 9, 2015 at 5:31 PM, Brian Wickman wrote: > > > +1 > > > > On Mon, Feb 9, 2015 at 1:55 PM, Joshua Cohen > > wrote: > > > > > I'd love to help out with this as well. > &g

Re: Seeking volunteers to create scheduler REST API RFC

Fantastic, thanks! On Tuesday, February 10, 2015, Henry Saputra wrote: > BIll, > > I helped built Telemetry RESTful APIs before so I could help. > > Count me in please. > > - Henry > > On Tue, Feb 10, 2015 at 4:55 PM, Bill Farner > wrote: > > Reviving thi

Re: Seeking volunteers to create scheduler REST API RFC

2.0 end point? > > > > > > ~ Joestein > > > > > > On Mon, Feb 9, 2015 at 5:31 PM, Brian Wickman > > wrote: > > > > > > > +1 > > > > > > > > On Mon, Feb 9, 2015 at 1:55 PM, Joshua Cohen < > jco...@twopensou

Re: Build failed in Jenkins: Aurora #871

This test has flaked twice today. Wickman - are you aware of any test cases that might be tripping this? -=Bill On Mon, Feb 9, 2015 at 3:14 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [maxim] Fixing test

Seeking volunteers to create scheduler REST API RFC

Hi folks, Before embarking on work [1] to build a REST* API for the scheduler, it's important that we come up with a sound design. Following up from today's IRC meeting, i would like to gather a small contingent (<=4 people) to collaborate on an RFC to drive a broader design discussion. Note tha

Re: Issues with Aurora Hello World

This is now fixed on master (dcae1e8). -=Bill On Sun, Feb 8, 2015 at 7:54 AM, Bill Farner wrote: > Hey Oliver, > > Thanks again for bringing this to our attention! This was caused by a > recently-introduced bug as part of a refactor: > https://issues.apache.org/jira/plugins

Re: Issues with Aurora Hello World

Hey Oliver, Thanks again for bringing this to our attention! This was caused by a recently-introduced bug as part of a refactor: https://issues.apache.org/jira/plugins/servlet/mobile#issue/AURORA-1115 This should be fixed by EOD Monday. In the meantime, you should have better luck if you reset y

Re: Aurora adopters list

I agree that the format will not scale. Steve pointed out to me Docker's use cases page [1] as an example. I like their format a *lot* more, since it gives us a place to indicate the degree to which a company uses our software. [1] https://www.docker.com/resources/usecases/ -=Bill On Thu, Feb

Re: [Announcement] New Committer: Joshua Cohen

Welcome aboard! On Tuesday, February 3, 2015, Jake Farrell wrote: > On behalf of the Apache Aurora PPMC, I would like to welcome our newest > committer to the project: > > Joshua Cohen > > He has been extremely active contributing quality patches as well as > helping > the community by ans

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

+1 Signature and checksums are good, test suite passes, end-to-end tests pass. -=Bill On Sat, Jan 31, 2015 at 7:52 PM, Maxim Khutornenko wrote: > All, > > I propose that we accept the following release candidate as the official > Apache Aurora 0.7.0 release. > > > Aurora 0.7.0-rc3 includes the

Re: AURORA-507

ies ? Is there > a force release mechanism ? > > Thanks, > Arunabha > > On Fri, Jan 30, 2015 at 5:09 PM, Bill Farner > wrote: > > > Correct, they are global and durable. > > > > -=Bill > > > > On Fri, Jan 30, 2015 at 5:05 PM, Arunabha Ghosh >

Re: AURORA-507

er :-) > > > > On Fri, Jan 30, 2015 at 11:22 AM, Bill Farner > wrote: > > > >> I think the guidance i gave you early on may have been overkill. You > >> might > >> consider isolating your change to SchedulerThriftInterface, and filter > the &g

Re: AURORA-507

oach I outlined feasible ? > > Thanks, > Arunabha > > On Thu, Jan 29, 2015 at 11:16 AM, Bill Farner wrote: > > > The missing detail is that MyBatis dynamically creates an implementation > of > > LockMapper based on LockMapper.xml [1]. > > > > However, i&#x

Re: Working on AURORA-189

Your assessment is correct! -=Bill On Thu, Jan 29, 2015 at 10:58 PM, Arunabha Ghosh wrote: > 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.jav

Re: Heartbeat mechanism auditing

t's really nice if the administrator doesn't need to dig into logs to piece history back together. Maxim - can you elaborate on an example of the complexity you are concerned about? -=Bill On Thu, Jan 29, 2015 at 3:52 PM, Bill Farner wrote: > Here's the permalink 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

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: AURORA-507

t; > > > > > > > > Bill, not sure how I should get a JIRA username. I signed up for > > > > > Reviewboard though. > > > > > > > > > > > > I think you can just use the signup link on the login page at > > > > issues.apache.org/jira

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

+1 Builds pass, end-to-end tests pass, signature and checksums are green. -=Bill On Tue, Jan 27, 2015 at 5:25 PM, Maxim Khutornenko wrote: > All, > > I propose that we accept the following release candidate as the official > Apache Aurora 0.7.0 release. > > > Aurora 0.7.0-rc2 includes the foll

Re: AURORA-507

I don't believe we have really discussed the future of these RPCs, and specifically whether we will remove the ability for users to implement client-side updaters. I think a broader discussion on the future of job updates is warranted if you'd like to propose removing that set of RPCs. -=Bill On

Re: AURORA-507

Tickets that are unassigned are usually not in progress, so feel free to step in! We'll need to add you to the list of users that can be assigned tasks in our JIRA queue, so please send me your JIRA user name. A good place to start would be a test case in SchedulerThriftInterfaceTest [1] with the

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

Yes, i also bumped into https://issues.apache.org/jira/browse/AURORA-1060 on one out of 3 attempts. I'm overall +0 at this point since i have not been able to successfully run tests. -=Bill On Tue, Jan 27, 2015 at 11:50 AM, Kevin Sweeney wrote: > Anyone else seeing test_thermos_executor.py ha

Re: Build failed in Jenkins: Aurora #841

es.txt) in my docker patch, however the tests > worked fine in my branch? > > On Mon, Jan 26, 2015 at 3:57 PM, Bill Farner wrote: > > > Funny, this did not trip for me locally on the branch, but i can now > repro > > on master. Taking a look. > > > > -=

Re: Build failed in Jenkins: Aurora #841

Funny, this did not trip for me locally on the branch, but i can now repro on master. Taking a look. -=Bill On Mon, Jan 26, 2015 at 12:55 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [wfarner] Fix impedan

Re: Mesos dependency upgrade?

+1! On Monday, January 26, 2015, Jake Farrell wrote: > Hey Steve > We typically have been upgrading our Apache Mesos version when the new > version has been released, looks like we all had other things on our plates > and missed this one. Don't see any reason not to update, if you want to > crea

Re: Thermos external component deprecation plan

+1, thanks for the braindump, Brian! This sounds great. -=Bill On Sat, Jan 24, 2015 at 8:43 AM, Joe Smith wrote: > Thanks for the write up! > > > On Jan 22, 2015, at 13:27, Brian Wickman wrote: > > > > Thermos is a standalone task execution system that is not coupled to > Aurora > > or Mesos.

Re: When (if ever) should we require JDK 8?

ng JDK8, and soon. > > On Thu, Jan 22, 2015 at 11:50 AM, Bill Farner wrote: > > > Hi folks, > > > > JDK 8 was officially released in March 2014, and brought a bunch of new > > features to the runtime and compiler. A side-effect of using java 8 > > langu

When (if ever) should we require JDK 8?

Hi folks, JDK 8 was officially released in March 2014, and brought a bunch of new features to the runtime and compiler. A side-effect of using java 8 language features is that it requires a >= 1.8 runtime, This means users currently running the scheduler with java 1.7 would need to upgrade their

Re: Upcoming deadlines to drive Aurora graduation

Thanks a lot for preparing this, Dave! I do hope we can advance the whole schedule a week or two by kicking off the 0.7.0 vote this week, but this is a good conservative schedule to make the target date. -=Bill On Tue, Jan 20, 2015 at 4:57 PM, Dave Lester wrote: > Hi All, > > I'm psyched to he

Re: Next Apache Aurora IRC meeting, rescheduled for Tuesday 1/20?

Thanks, Jake! -=Bill On Tue, Jan 20, 2015 at 4:04 PM, Jake Farrell wrote: > i resent it to the correct address, should arrive shortly > > -Jake > > On Tue, Jan 20, 2015 at 5:05 PM, Bill Farner wrote: > > > Sorry, I typoed the mailing list when instructing ASFBot. Whe

Re: Next Apache Aurora IRC meeting, rescheduled for Tuesday 1/20?

Sorry, I typoed the mailing list when instructing ASFBot. When I get back to my desk I will see if I can send it again. On Tuesday, January 20, 2015, Maxim Khutornenko wrote: > It should have been sent, though I can't find it in my mailbox for some > reason. > > http://wilderness.apache.org/arc

Re: Next Apache Aurora IRC meeting, rescheduled for Tuesday 1/20?

+1 On Saturday, January 17, 2015, Dave Lester wrote: > > Hi All, > > The Aurora community regularly holds IRC meeting on Mondays at 11am PST, > however this upcoming Monday (1/19) is Martin Luther King day in the United > States. > > Since this American federal holiday affects many folks who act

Welcome, Zameer! New committer/PMC member

I'm proud to announce that Zameer Manji has accepted the Apache Aurora PMC's invitation to become a committer and PMC member. Thanks again for all your hard work, Zameer! We're happy to have you aboard! -=Bill

Re: Build failed in Jenkins: Aurora #823

Turns out there are two misconfigured jenkins slaves. I've blacklisted this one from our build as well. -=Bill On Mon, Jan 12, 2015 at 11:44 AM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [dave] Removes doc

Invitation to become an Apache Aurora committer: Zameer Manji

Zameer Manji, The Apache Aurora Project Management Committee (PMC) hereby offers you committer privileges and membership in the PMC of the Apache Aurora project. These privileges are offered on the understanding that you'll use them reasonably and with common sense. We like to work on trust rather

Re: Getting INVALID_REQUEST for createJob api

Unfortunately this is a known wart in /apibeta, and a symptom of why it will never graduate from beta in the current form. The details behind why you see this is that we use Gson to deserialize JSON, which does not support to the JavaBean convention, using getter and setter methods. Thrift, on th

Should we continue to maintain fine-grained python BUILD targets?

We currently have ~111 BUILD targets serving our python code, and ~106 test targets: $ find . -name BUILD | xargs grep python_library | wc -l 111 $ find . -name BUILD | xargs grep python_test | wc -l 106 This presents a non-trivial maintenance burden, and i'm not convinced the benefits are worth

Re: Build failed in Jenkins: Aurora #803

This was an artifact fetch failure: Exception message: Failed to fetch https://pypi.python.org/packages/source/w/wheel/wheel-0.23.0.tar.gz#md5=273374d28127b821d61cdfe56e7c35dd to /tmp/user/2395/tmp5mleoN: Could not reach https://pypi.python.org/packages/source/w/wheel/wheel-0.23.0.tar.gz#md5=27337

Re: api vs apibeta

I added it as a proof of concept, and a temporary solution to retrofit our current API to make it more consumable. Unfortunately, i don't think there's any sane way for it to become supported, and we should instead focus on a first-class REST-like API. I realized while we intended to do this, we

Re: Constantly getting TASK_LOST from Mesos and THROTTLED from Aurora

This appears suspect: Fetching URI '/dev/null' On the scheduler, what's the value supplied for the --thermos_executor_path command line argument? -=Bill On Mon, Dec 8, 2014 at 12:31 PM, Larry Weya wrote: > I built Aurora from source and I'm running Mesos 0.21.0 > > While trying to run the

Re: 0.7.0 Release Manager

FWIW the burden in being release manager is more of organization and learning the release protocols than anything else. The technical technical requirements are not significant. -=Bill On Mon, Dec 8, 2014 at 11:26 AM, Zameer Manji wrote: > We need a release manager for 0.7.0. Ideally we select

Re: Build failed in Jenkins: Aurora #785

Looks like a flaky test. Kicking off another build before diverting attention to fix the build. -=Bill On Mon, Dec 8, 2014 at 10:17 AM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [wfarner] Don't fall back t

Re: Build failed in Jenkins: Aurora #781

https://reviews.apache.org/r/28738/ -=Bill On Thu, Dec 4, 2014 at 6:26 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [wfarner] Drop custom thrift doc generator in favor of the one included in > thrift. > >

Re: Build failed in Jenkins: Aurora #776

https://reviews.apache.org/r/28660/ -=Bill On Wed, Dec 3, 2014 at 10:58 AM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [wfarner] Add a caching ClusterState implementation. > > ---

Re: aurora watch_secs change

Also relevant to this is AURORA-279, which suggests that we may not want to special-case the startup phase. Additional context - we should lean towards using mesos' framework messages as the communication medium. These messages are one-way, rather than request-response based. This seems to rule

Re: [DISCUSS] Features for 0.7.0

be a good patch, it'd be nice to get a release sooner than > mid-Q1 which seems a ways off. Maybe we can up the release cadence a bit > more to make this possible. > > > Dave > > -Original Message- > From: "Bill Farner" > Sent: Monday, December

Re: [DISCUSS] Features for 0.7.0

-915 as possible candidate for > inclusion to 0.7.0 (at the very least, warn-on-import and providing a > binding helper for os.environ.) > > On Mon, Dec 1, 2014 at 3:04 PM, Bill Farner wrote: > > > It is not yet tracked in our end - we have yet to think about what mesos'

Re: [DISCUSS] Features for 0.7.0

> Joe Stein > Founder, Principal Consultant > Big Data Open Source Security LLC > http://www.stealth.ly > Twitter: @allthingshadoop > ********/ > On Dec 1, 2014 4:17 PM, "Bill Farner" wrote: > > > Now that 0.6.0 is butto

[DISCUSS] Features for 0.7.0

Now that 0.6.0 is buttoned up, it's time to think about what we would like to shoot for in 0.7.0 [1]! Framing the discussion - i'd like to suggest we keep 0.7.0 a 'minor' release to allow us to wrap it up by mid Q1. So while lofty goals are more than welcome in JIRA, let's be somewhat resistant t

Re: Proposal: Aurora blog posts for each release

+1, majorly useful -=Bill On Mon, Dec 1, 2014 at 10:12 AM, Joe Stein wrote: > +1 makes keeping track of these things really helpful and useful, would be > great > > On Mon, Dec 1, 2014 at 1:09 PM, Dave Lester wrote: > > > > > Hi All, > > > > I'd like to suggest that for the most-recent and fut

[RESULT] [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

Hi everyone, This vote passed with three +1 binding IPMC member votes from: Jake Farrell Henry Saputra Benjamin Hindman There were no 0 or -1 votes. Thanks! -=Bill On Fri, Nov 21, 2014 at 11:32 AM, Bill Farner wrote: > Hi All, > > The Apache Aurora project has voted to rele

Re: Updated website

Thanks, Kevin!! -=Bill On Fri, Nov 21, 2014 at 1:18 PM, Kevin Sweeney wrote: > I updated the homepage with overview content from our README.md. > > I've also updated our downloads page to reference our release > (0.5.0-incubating, soon to be 0.6.0-incubating). > > I also fixed our dropdown (we

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

I see using mock.patch as equivalent to extending a class and changing the behavior of a method, which i strongly prefer to avoid. At the very least, we should strictly avoid patching behavior layers down in the stack of what is being tested. I'd be happy with punting on a best practice to eradic

[VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

0-incubating. This vote will be open for 72 hours. Cheers, Bill -- Forwarded message -- From: Bill Farner Date: Fri, Nov 21, 2014 at 11:16 AM Subject: [RESULT] [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2 To: "dev@aurora.incubator.apache.org" Hi All, The

[RESULT] [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

Hi All, The vote to accept Apache Aurora 0.6.0 RC2 as the official Apache Aurora 0.6.0 release has passed. +1 (Binding): --- Maxim Khutornenko David McLaughlin Kevin Sweeney Jake Farrell Henry Saputra Bill Farner Benjamin Hindman +1 (Non-binding

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

g) > > Thanks guys! > > On Thu, Nov 13, 2014 at 2:33 PM, Bill Farner wrote: > > All, > > > > I propose that we accept the following release candidate as the official > > Apache Aurora 0.6.0 release. > > > > > > Aurora 0.6.0-rc2 includes

[VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

All, I propose that we accept the following release candidate as the official Apache Aurora 0.6.0 release. Aurora 0.6.0-rc2 includes the following: --- The CHANGELOG for the release is available at: https://git-wip-us.apache.org/repos/asf?p=incubator-aurora.git&f=CHANGELOG&hb=0.6.0-rc2 The bran

[RESULT] [VOTE] Release Apache Aurora 0.6.0 (incubating) RC1

Since we have discovered a release-blocking bug, declaring this vote failed. RC2 to follow. -=Bill -- Forwarded message -- From: Bill Farner Date: Thu, Nov 13, 2014 at 1:00 PM Subject: Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC1 To: "dev@aurora.incubator.apach

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

7;. > > > > > > > > > > * Try: > > > > > Run with --stacktrace option to get the stack trace. Run with > --info > > or > > > > > --debug option to get more log output. > > > > > > > > > > BUILD FAILED > &

  1   2   3   4   5   >