Build failed in Jenkins: aurora-packaging-nightly #156

See Changes: [zmanji] Enable H2 query statistics collection. -- [...truncated 34594 lines...] 00:48:57 00:08 [dup] 00:48:57 00:08 [complete] SUCCESS

Re: Parameterize each Job Instance.

There's a chicken and egg problem though. That variable will only be filled in on the executor, when we're already running in the docker environment. In this case, the parameter is used to *define* the docker environment. On Mon, Jan 11, 2016 at 9:07 PM, ben...@gmail.com wrote:

Re: Parameterize each Job Instance.

On Mon, Jan 11, 2016 at 10:10 PM, Bill Farner wrote: > There's a chicken and egg problem though. That variable will only be filled > in on the executor, when we're already running in the docker environment. > In this case, the parameter is used to *define* the docker

Re: [PROPOSAL] Replace commons-args

Any other thoughts on this? I will proceed with initial encapsulation work in the meantime, but am interested in any other pro/con opinions. On Fri, Jan 8, 2016 at 10:25 AM, Maxim Khutornenko wrote: > "Can you turn that concern into a more firm stance?" - you mastered > the

Parameterize each Job Instance.

Hi guys, We are using the docker rbd volume plugin to provide persistent storage to the aurora jobs that runs in the containers. Something like: p = [Parameter(name='volume', value='my-ceph-volume:/foo'), ...] jobs = [

Re: Parameterize each Job Instance.

As a starting point, you might be able to cook up something involving {{mesos.instance}} as a lookup key to a pystachio list. You do have a unique integer task number per instance to work with. cf. http://aurora.apache.org/documentation/latest/configuration-reference/#template-namespaces On

Re: Parameterize each Job Instance.

On Mon, Jan 11, 2016 at 10:40 PM, Bill Farner wrote: > Funny, that's actually how the scheduler API originally worked. I think > this is worth exploring, and would indeed completely sidestep the paradigm > shift i mentioned above. > I think the crux might be handling a

Re: Parameterize each Job Instance.

I agree that this appears necessary when parameters are needed to define the runtime environment of the task (in this case, setting up the docker container). What's particularly interesting here is that this would call for the scheduler to fill in the parameter values prior to launching each

Jenkins build is back to normal : Aurora #1327

See

Re: Parameterize each Job Instance.

In the log, tasks are denormalized anyhow: https://github.com/apache/aurora/blob/master/api/src/main/thrift/org/apache/aurora/gen/storage.thrift#L43-L45 On Mon, Jan 11, 2016 at 9:54 PM, John Sirois wrote: > On Mon, Jan 11, 2016 at 10:40 PM, Bill Farner

Re: Parameterize each Job Instance.

On Mon, Jan 11, 2016 at 11:00 PM, Bill Farner wrote: > In the log, tasks are denormalized anyhow: > > https://github.com/apache/aurora/blob/master/api/src/main/thrift/org/apache/aurora/gen/storage.thrift#L43-L45 Right - but now we'd be making that denormalization

Heads up - new release tagging protocol

tl;dr: release tags are changing to the format rel/0.11.0. no more release branches. Recent changes to configuration of Apache's git server have added protections to tags prefixed by rel/. We are going to take advantage of this so that our release tags are immutable on the git server. Since

Build failed in Jenkins: Aurora #1326

See Changes: [zmanji] Enable H2 query statistics collection. -- [...truncated 3345 lines...]

Summary of IRC Meeting in #aurora

Summary of IRC Meeting in #aurora at Mon Jan 11 19:17:01 2016: Attendees: jsirois, mkhutornenko, jcohen, zmanji - Preface - increased community growth IRC log follows: ## Preface ## [Mon Jan 11 19:17:21 2016] : meeting time! [Mon Jan 11 19:17:27 2016] : lets start off with rollcall [Mon Jan