Re: [VOTE] Move Aurora to Apache Attic

+1 Aurora has always been about pragmatism, and right now, this is the best route for new and existing users. On Fri, Jan 31, 2020 at 5:13 PM Renan DelValle wrote: > +1 (with a fair bit of sadness but hope for the future of the project) > > 2020-01-31 17:11 GMT-08:00 Renan DelValle: > > Folks,

Re: Combining limit and dedicated constraint

I’m pretty sure I’ve seen this combination working in the (distant) past, for limit:1 and other values. As a sanity check, if you remove the host that _is_ having the task scheduled, does the task move to the other host? On Mon, Feb 4, 2019 at 5:10 PM Renan DelValle wrote: > I have two

Re: Volunteers needed

I’m happy to pitch in for periodic review. Anyone is welcome to email me requesting a review. I don’t monitor incoming reviews, so unfortunately I will need to be contacted out-of-band. On Tue, Sep 18, 2018 at 10:45 AM Renan DelValle wrote: > All, > > We are in dire need of folks who would be

Re: Transient task state timeout

This is expected behavior, as STARTING is not a transient state . I don't believe it ever was. The rationale is that the ASSIGNED -> STARTING transition acknowledges the

Re: snapshot analyze

You might be thinking of something we had at Twitter geared towards capacity planning. It intended to tell us how many more instances of a given resource shape would hypothetically “fit” in the cluster. > On Jun 6, 2018, at 1:20 AM, meghdoot bhattacharya > wrote: > > Long time back, I

Re: Recovery instructions updates

> > How does the site get updated? Is it auto-generated when we build releases? The source lives in the project SVN repo: $ svn co https://svn.apache.org/repos/asf/aurora/ aurora-svn Here are instructions for updating it. It's a pretty

Re: [VOTE] Discontinue Official Binary Package releases

+1 > On May 18, 2018, at 6:44 PM, Renan DelValle wrote: > > +1 > > On Fri, May 18, 2018 at 6:35 PM, Mauricio Garavaglia < > mauriciogaravag...@gmail.com> wrote: > >> +1 >> >>> On Fri, May 18, 2018 at 8:01 PM, Renan DelValle wrote: >>> >>> All, >>> >>>

Re: Scheduling improvements followups

> > How much work (and feasibility?) would be to add other filter conditions In my opinion, relatively little work. An extension point exists as a thin interface [1], injectable via a module [2]. OfferOrder [3] may look like a promising alternative, but i see that as a less flexible option.

Re: [VOTE] Release Apache Aurora 0.19.1 RC0

+1, binding I did encounter a unit test failure, but maintain my +1 as this test case has been notorious flaky on macOS 10.13.3 (especially for me, apparently). All other checks in the verification script pass. def _run_collector_tests(collector, target, wait): assert

Welcome new committers and PMC member!

Folks, I'm happy to announce that we have two new developers on the project! Renan DelValle is now a committer and PMC member Jordan Ly is now a committer Welcome aboard, we're looking forward to your continued contributions! -=Bill

Re: [RESULT] [VOTE] Release Apache Aurora 0.19.x packages

> There's been a few folks on the Slack channel have been asking when the > binaries for 0.19 will be released. > > -Renan > > On Wed, Dec 13, 2017 at 5:23 PM, Bill Farner <wfar...@apache.org> wrote: > > > I reverse my vote to -1 and am closing the vote as failed. &

Re: replicated log improvement

I think it aligns well with work that plausibly follows r/64288/ , so i'd say it's a likely outcome regardless of the direction taken for storage. On Wed, Jan 3, 2018 at 11:44 PM, meghdoot bhattacharya < meghdoo...@yahoo.com.invalid> wrote: > mesos 7973

Re: executor id from task id?

> create one. I don't want to add it to storage if it is not there to avoid > handling db migration. > > On Tue, Jan 2, 2018 at 8:05 PM, Bill Farner <wfar...@apache.org> wrote: > > > Did your code search lead you here > > <https://github.com/apache/aurora/blob/2e1ca

Re: executor id from task id?

Did your code search lead you here ? It should show how the executor and task IDs relate. On Tue, Jan 2, 2018 at 1:08 PM, Mohit Jaggi

Re: [REPORT] Apache Aurora - December 2017

+1 Thanks, Jake! On Mon, Dec 18, 2017 at 6:34 AM, Jake Farrell wrote: > Please find below the draft report for December, if anyone has any > modifications or additions please let me know > > -Jake > > > > Apache Aurora is a stateless and fault tolerant service scheduler

[RESULT] [VOTE] Release Apache Aurora 0.19.x packages

s/aurora-ubuntu-trusty/dist > > Oddly enough, we have deployed 0.19.0 packages for trusty without any issue > on at least two of our test clusters so it may have to do with our > artifacts tests? > > I tried upgrading the trusty box to Mesos 1.2.2 and the problem persisted. &g

Re: [VOTE] Release Apache Aurora 0.19.x packages

> > +0, we don't use the packages. If you just need someone to test and > verify, > > I can do that. Let me know. > > > > On Tue, Dec 12, 2017 at 9:53 AM, Bill Farner <wfar...@apache.org> wrote: > > > > > Friendly reminder that the vote is du

Re: [VOTE] Release Apache Aurora 0.19.x packages

Friendly reminder that the vote is due to close tomorrow! Stephan - is the issue you described reproducible? Did i run the same test command(s) as you? On Sun, Dec 10, 2017 at 8:32 PM, Bill Farner <wfar...@apache.org> wrote: > +1 from me, as the test script passes for all artifacts

Re: [VOTE] Release Apache Aurora 0.19.x packages

l URIs for container '48b4029a-231d- > 441a-98a6-8c6538fe0efa' with exit status: 256 > > > Did those tests work for you? > > > In addition, but most probably unrelated, the branch is missing on http > s://github.com/apache/aurora-packaging. The ASF bot might have missed

[VOTE] Release Apache Aurora 0.19.x packages

All, I propose that we accept the following artifacts as the official deb and rpm packaging for Apache Aurora 0.19.x: https://dl.bintray.com/bill/aurora/ The Aurora deb and rpm packaging includes the following: --- The branch used to create the packaging is:

[RESULT][VOTE] Release Apache Aurora 0.19.0 RC0

All, The vote to accept Apache Aurora 0.19.0 RC0 as the official Apache Aurora 0.19.0 release has passed. +1 (Binding) -- Bill Farner David McLaughlin Stephan Erb +1 (Non-binding) -- Mohit Jaggi There were no 0 or -1 votes. Thank you

Re: [VOTE] Release Apache Aurora 0.19.0 RC0

> > > +1 > > > > On Tue, Nov 7, 2017 at 10:51 PM, Bill Farner <wfar...@apache.org> wrote: > > > > > +1 > > > > > > Successfully validated with ./build-support/release/ > > > verify-release-candidate > > > 0.19.0-rc0 >

Re: [VOTE] Release Apache Aurora 0.19.0 RC0

r than a supported environment. Others are welcome to feel differently. On Tue, Nov 7, 2017 at 8:49 PM, Bill Farner <wfar...@apache.org> wrote: > All, > > I propose that we accept the following release candidate as the official > Apache Aurora 0.19.0 release. > > Aurora 0.1

[VOTE] Release Apache Aurora 0.19.0 RC0

All, I propose that we accept the following release candidate as the official Apache Aurora 0.19.0 release. Aurora 0.19.0-rc0 includes the following: --- The RELEASE NOTES for the release are available at: https://git-wip-us.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.19.0-rc0 The

Re: 0.19.0 release preparation

tstanding regressions I'll get to this week, one is minor and > one is relatively serious (no longer showing pending reasons on the task > list). If people are comfortable moving forward without those fixes, then > go for it. > > On Tue, Nov 7, 2017 at 9:55 AM, Bill Farner &l

Re: 0.19.0 release preparation

> > > I planned on upgrading to Mesos 1.4. Unfortunately this is currently > > blocked by a missing mesos.interface package on PyPI. I send a mail out > to > > the Mesos Dev list but I am still waiting for a response. So this will > have > > to wait for 0.2

Re: [VOTE] Release Apache Aurora 0.18.1 RC1

ed in 0.18.1 but no strong opinions. > > +0 > > On Mon, Oct 30, 2017 at 12:06 PM, Stephan Erb <s...@apache.org> wrote: > > > +1 > > > > Thanks for handling this, Bill. > > > > On Mon, 2017-10-30 at 10:05 -0500, Joshua Cohen wrote: > >

Re: Build failed in Jenkins: Aurora #1858

GB. I simply added the remaining 2 > as an additional safeguard when something else is launched on the > Jenkins node shortly after we have passed the guard. > > On Tue, 2017-10-24 at 21:38 -0700, Bill Farner wrote: > > Possibly rehashing an old discussion - does the build really require &g

Re: [VOTE] Release Apache Aurora 0.18.1 RC1

> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0 > curl: (22) The requested URL returned error: 404 Not Found > > > On Sun, Oct 29, 2017 at 5:03 PM, Bill Farner <wfar...@apache.org> wrote: > > > +1 > > > > Verified by running ./build-

Re: [VOTE] Release Apache Aurora 0.18.1 RC1

+1 Verified by running ./build-support/release/verify-release-candidate 0.18.1-rc1 On Sun, Oct 29, 2017 at 12:05 PM, David McLaughlin <dmclaugh...@apache.org> wrote: > +1 > > On Sun, Oct 29, 2017 at 10:32 AM, Bill Farner <wfar...@apache.org> wrote: > > > All, &g

[VOTE] Release Apache Aurora 0.18.1 RC1

All, I propose that we accept the following release candidate as the official Apache Aurora 0.18.1 release. Aurora 0.18.1-rc1 includes the following: --- The RELEASE NOTES for the release are available at: https://git-wip-us.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.18.1-rc1 The

Re: Build failed in Jenkins: Aurora #1858

Possibly rehashing an old discussion - does the build really require 4 GB? On Mon, Oct 23, 2017 at 1:53 PM, Erb, Stephan wrote: > Ah, again a node with insufficient memory. I once added a mechanism to > abort the build early rather than running and eventually

Re: gorealis is now officially a PayPal Open Source Project

Congrats on releasing! On Oct 16, 2017, 4:15 PM -0500, Renan DelValle , wrote: > Hi all, > > Just wanted to drop a note about a recent update for gorealis[1]. For those > who aren't familiar with it, gorealis is a library that aims to enable > users to programmatically

Re: Future of storage in Aurora

converting it have an impact on, e.g., > storage write-lock contention? > > On Sun, Oct 1, 2017 at 5:59 PM, Bill Farner <wfar...@apache.org> wrote: > > > I would like to revive this discussion in light of some work i have been > > doing around the storage system. The

Re: Future of storage in Aurora

> > On 02.10.17, 00:59, "Bill Farner" <wfar...@apache.org> wrote: > > I would like to revive this discussion in light of some work i have been > doing around the storage system. The fruits of the DB storage system will > require a lot of additional effort to reach

Re: Future of storage in Aurora

ed by performance, I'd verify there is a benefit before > > submitting > > any review. > > > > Thanks all for the feedback. > > > > > > On Thu, Mar 30, 2017 at 12:08 PM, Bill Farner <wfarnerapa...@gmail.co > > m> > > wrote: > >

Notice - removing rewriteConfigs API call

FYI - i have a patch out for review that will remove the rewriteConfigs thrift API call, with no deprecation period (see the review for rationale). Currently there is movement to land the patch. If you use or care about this API call, please chime in ASAP!

Re: ResourceBag Ordering violates general contract

I've implemented the above suggestion here: https://reviews.apache.org/r/61238/ On Fri, Jul 28, 2017 at 7:19 PM, Bill Farner <wfar...@apache.org> wrote: > Neat bug! > > The implementation gets into trouble when different resource types are in > play, giving inconsistent

Re: Reducing Failover Time by Eagerly Reading/Replaying Log in Followers

Some (hopefully) constructive criticism: - the doc is very high-level on the problem statement and the proposal, making it difficult to agree with prioritization over cheaper snapshots or the oft-discussed support of an external DBMS. - the supporting data is a single data point of the

Re: A sketch for supporting mesos maintenance

(1) sounds like an inevitability, do you have a sense of what stands in the way, or what it will take? (2) is a win for ending behavior redundancy. This is probably in the doc, but I'm lazy - are maintenance statuses surfaced in offers? IIRC the original incarnation of maintenance modes in mesos

Re: /offers endpoint is being modified

Sounds like the patch should include a comment in the release notes. On Tuesday, July 19, 2016, Mehrdad Nurolahzade wrote: > Hi All, > > As part of AURORA-1736 > and to facilitate future development for Dynamic

Re: mesos-log health check HTTP endpoint

ecovery. But if you start doing upgrade on 2nd instance before mesos-log > is replicated to first one its easy to loose quorum and data. I'd like to > have some deterministic check that would allow to ensure that its safe to > consider log replicated. > > 2016-06-17 16:05 GMT+02:00 Bill Fa

Re: mesos-log health check HTTP endpoint

If i recall correctly, the current implementation of the mesos log requires that the callers handle mutually-exclusive access for reads and writes. This means that non-leading schdulers may not read or write to perform the check you describe. What's the behavior of the scheduler when it starts

Re: [FEEDBACK] Transitioning Aurora leader election to Apache Curator (`-zk_use_curator`)

> > Assuming we don't run into any roadblocks: How about changing the > default of `-zk_use_curator` from False to True for the next release? +1 I believe that was the plan of action, though i can't recall if it was recorded anywhere more official than the dev list. On Wed, Jun 15, 2016 at

Re: Aurora performance impact with hourly query runs

___ > >>>>> From: Shyam Patel <sham.pate...@gmail.com <javascript:;>> > >>>>> Sent: Thursday, June 9, 2016 07:48 > >>>>> To: dev@aurora.apache.org <javascript:;> > >>>>> Subject: Re: Auro

Re: Aurora performance impact with hourly query runs

Can you give some insight into the machine specs and JVM options used? Also, is it 8000 jobs or tasks? The terms are often mixed up, but will have a big difference here. On Wednesday, June 8, 2016, Shyam Patel wrote: > Hi, > > While running LnP testing, I’m spinning of

Re: Subscribing to Aurora's tasks' event changes

Fwiw I would favor a first-class mechanism instead. I think pointing to auth modules as a successful pattern is a mistake. On Monday, April 25, 2016, Zameer Manji wrote: > I think a good approach to take would be to have `PubsubEventModule` take > modules as an arg like

Re: experimental require_docker_use_executor

There's no real roadmap for this feature, i added it just because a bunch of people had been asking and i finally found a personal need for it :-) Adding support for CMD sounds great. Could you approach it by adding a field to DockerContainer [1]? [1]

Re: [VOTE] Release Apache Aurora 0.13.0 RC0

t; > stephan@blue-yonder.com> > > > wrote: > > > > > > > +1 for releasing 0.13.0-rc0 as Aurora 0.13.0 > > > > > > > > * tested with the verification script > > > > * deployed the RC to an inhouse test cluster > > >

Re: Upgrade executor without restarting task

Correct, you cannot currently do this. Can you share the what motivates this need? Do you plan on iterating rapidly on the executor in production? In general, one of the principles of a system like Aurora is to embrace the reality that components can be restarted without warning; which enables

Re: [DISCUSS]: 0.13.0 release candidate

g> > Sent: Monday, April 4, 2016 23:14 > To: dev@aurora.apache.org > Subject: Re: [DISCUSS]: 0.13.0 release candidate > > +1 > > On Mon, Apr 4, 2016 at 2:10 PM, Zameer Manji <zma...@apache.org> wrote: > > +1 > > > > On Mon, Apr 4, 2016 at 12:27 PM, Bill Far

Re: [PROPOSAL] Support GPU resources in Aurora

There has been separate discussion around supporting arbitrary resources. Is it plausible to build that and get GPU support for free? On Wed, Apr 6, 2016 at 10:41 AM, Maxim Khutornenko wrote: > Mesos community is finalizing their MVP for supporting GPUs: >

Re: Are we ready to remove the observer?

ocess left to host the http server, there is no way to > access that data in the current way of things. > > On Mon, Apr 4, 2016 at 3:54 PM, Bill Farner <wfar...@apache.org> wrote: > >> > >> It falls apart for terminal tasks when executor process is not running > >> any

Re: Are we ready to remove the observer?

Mon, Apr 4, 2016 at 1:54 PM, Zameer Manji <zma...@apache.org> wrote: > On Mon, Apr 4, 2016 at 1:47 PM, Bill Farner <wfar...@apache.org> wrote: > > > We clearly have different experiences - i've never really benefited from > > viewing the process graph, as most jobs ha

Re: [DISCUSS]: 0.13.0 release candidate

+1, fire away On Mon, Apr 4, 2016 at 12:26 PM, Jake Farrell wrote: > Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it > looks like we are about ready to cut the 0.13.0 release candidate and start > a vote. I wanted to open the floor up for any last

Re: Are we ready to remove the observer?

dev@aurora.apache.org > > > Subject: Re: Are we ready to remove the observer? > > > > > > Is there any chance we can keep the per-process cpu and ram utilization > > > stats? That's one of the coolest things about aurora, imo. The > executor > > >

Are we ready to remove the observer?

Assuming that the vast majority of utility provided by the observer is sandbox/log browsing - can we remove it and link to sandbox browsing that mesos provides? The rest of the information could be (or already is) logged in the sandbox for the rare debugging scenarios that call for it.

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

the credentials file. On Tue, Mar 29, 2016 at 2:39 PM, John Sirois <j...@conductant.com> wrote: > On Tue, Mar 29, 2016 at 3:26 PM, Bill Farner <wfar...@apache.org> wrote: > > > If i'm understanding you correctly, that doesn't address preventing users > > from

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

aster/include/mesos/mesos.proto#L422 > > > > > > On Tue, Mar 29, 2016 at 4:26 PM, Bill Farner <wfar...@apache.org> wrote: > > > > > I'm in favor of moving forward. There's no requirement to use the > > > Announcer, and a non-root executor seems lik

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

> choose. Is there any interest in the feature I proposed or should I just > drop it? It's not a lot of code, but also it's not a requirement for > anything we're working on either (the docker stuff however, is). > > On Tue, Mar 29, 2016 at 1:39 PM, Bill Farner <wfar...@apache.org&g

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

That's correct - those credentials should require privileged access. On Tue, Mar 29, 2016 at 10:25 AM, Steve Niemitz < sniem...@twitter.com.invalid> wrote: > Re: ZK credential files, thats an interesting issue, I assume you don't > want the role user to be able to read it either, and only root

Re: aurora job scalability

> > Does job map to a Marathon application? I believe so, yes. An Aurora job is multiple replicas of a [group of] processes, usually (but not necessarily) homogeneous. If similar is there a known limitation to how many jobs one can have? This will depend on the hardware used for the

Re: [PROPOSAL] Rename NEWS to RELEASE-NOTES.md

to > making it easier to understand its purpose > > -Jake > > On Mon, Mar 14, 2016 at 4:27 PM, Bill Farner <wfar...@apache.org> wrote: > > > Our NEWS file has turned into a useful source of information, but i think > > the name doesn't clearly illustrate its

[PROPOSAL] Rename NEWS to RELEASE-NOTES.md

Our NEWS file has turned into a useful source of information, but i think the name doesn't clearly illustrate its purpose. Since we have been primarily using it to manage release notes, i propose we rename the file to RELEASE-NOTES.md. As the name implies, i also propose that we formally use

Re: [VOTE] Release Apache Aurora 0.12.0 rpms

+1 Verified using instructions starting here: https://github.com/apache/aurora-packaging/blob/master/test/rpm/centos-7/README.md#released and pkg_root="https://dl.bintray.com/john-sirois/aurora/centos-7/; On Mon, Mar 14, 2016 at 12:10 PM, John Sirois wrote: > I propose

Re: [VOTE] Release Apache Aurora 0.12.0 rpms

-1 I'm had trouble getting these to work. I used the vagrant environment here: https://github.com/apache/aurora-packaging/tree/master/test/rpm/centos-7 *Executor:* $ sudo rpm -ivh aurora-executor-0.12.0-1.el7.centos.aurora.x86_64.rpm error: Failed dependencies: docker is needed by

Re: Non-exclusive dedicated constraint

supply and demand sides. > > On Wed, Mar 9, 2016 at 2:26 PM, Bill Farner <wfar...@apache.org> wrote: > > What does it mean to have a 'dedicated' host that's free-for-all like > that? > > > > On Wed, Mar 9, 2016 at 2:16 PM, Maxim Khutornenko <ma...@apache.org> >

Re: Non-exclusive dedicated constraint

; > I believe I had talked to Bill about this a few months ago, but I > don't > >>> > remember where it ended up. > >>> > > >>> > [1] > >>> > > >>> > https://github.com/tellapart/aurora/commit/76f978c76cc1377e19e602f7e0d050f7ce35

Re: [VOTE] Release Apache Aurora 0.12.0 debs

+1 Successfully installed and lightly exercised ubuntu and debian packages in their respective systems (using test/ instructions in the aurora-packaging repo). On Mon, Mar 7, 2016 at 8:00 AM, John Sirois wrote: > I propose that we accept the following artifacts as the

Re: [RESULT][VOTE] Release Apache Aurora 0.12.0 RC4

r pacakegs but did not get time to > finish up. I likely won't get the docs published and RC out until Sunday. > > Apologies for the delays. > > On Feb 29, 2016 10:03 AM, "Bill Farner" <wfar...@apache.org> wrote: > > > > IIRC site changes aren't blocked

Re: Weekly community meeting

I think it's worth raising the topic of whether to continue regularly-scheduled meetings. Given the distributed community, it is difficult to find a time that routinely works for everyone. Eliminating this might also encourage more frequent use of the mailing list when discussion topics arise,

New committer and PMC member: Stephan Erb

Folks, Please join me in welcoming Stephan Erb, who is now an Aurora committer and PMC member! I'm sure anyone paying attention has noticed Stephan's involvement in the community and commitment to improving Aurora! Welcome aboard, Stephan!

Re: NEWS Layout

+1 On Tuesday, February 2, 2016, Erb, Stephan wrote: > Hi everyone, > > I'd like to propose that we give our NEWS file a little bit more > structure. Currently, it is quite cluttered [1]. > > To keep it simple, I'd suggest that we adopt the style from the 0.11 >

Re: Rollback Testing

1, 2016 at 2:40 PM, Bill Farner <wfar...@apache.org> wrote: > > > Definitely a nice thing to have, the big uncertainty will be whether > anyone > > cares enough to see the effort through. > > > > e2e tests in jenkins can be done, but likely only if e2e tests start &

Re: Deprecation Cycles

s, so feel free to push back if you think, e.g., > 60 days is more reasonable. > > On Mon, Feb 1, 2016 at 2:35 PM, Bill Farner <wfar...@apache.org> wrote: > > > Sounds reasonable. Can you firm up the proposal and apply numbers? > > > > On Mon, Feb 1, 2016

Re: [VOTE] Release Apache Aurora 0.12.0 RC0

(moved off private list) +1 (binding) Successfully verified using ./build-support/release/verify-release-candidate 0.12.0-rc0 On Wed, Jan 27, 2016 at 11:21 PM, John Sirois wrote: > All, > > I propose that we accept the following release candidate as the official > Apache

Re: [PROPOSAL] Change java thrift code gen

e's a lot of custom code that needs > to be maintained and a bunch of work to rebase the code periodically. > > > > On Wed, Jan 27, 2016 at 4:51 PM, Bill Farner <wfar...@apache.org> wrote: > > > Firstly - thanks for the clean organization and delineation of s

Re: [PROPOSAL] Revisit task ID format

; > > > > easier to correlate Mesos tasks to Aurora jobs when skimming log > > files, > > > > > viewing the Mesos-UI or even when using the Thermos [1]. I guess > the > > > > > traceability of all of those usecases could be improved, but that >

Re: [PROPOSAL] Change java thrift code gen

Firstly - thanks for the clean organization and delineation of steps in this change. Top notch work! Some of the performance improvements are very nice; and in a particularly hot code path. I will wager a guess that the majority of the savings is in avoiding what amounts to copy constructors

Re: [PROPOSAL] Revisit task ID format

ave to force this change over existing > tasks and let them die out naturally. Some user scraping tools may be > broken due to this but we always advised against taking a dependency on our > task ID format. > > +1 to the proposal. > > On Wed, Jan 27, 2016 at 5:46 PM, Bill Farner <wfar

[PROPOSAL] Revisit task ID format

Context: a task ID is a unique identifier for a task. Aurora and Mesos both require this uniqueness. Within mesos, frameworks are required to craft their own task IDs as they see fit. Our task ID format is currently [1] TIMESTAMP-ROLE-ENV-JOBNAME-INSTANCE-UUID for an example:

Re: PROPOSAL: Host and support nightly Aurora builds on Apache servers

FWIW we already link to nightlies from https://aurora.apache.org/downloads/ I think all that's needed here is an adjustment to the jenkins configuration to register the jessie debs as artifacts. On Fri, Jan 22, 2016 at 11:56 AM, Zameer Manji wrote: > +1 to just putting the

Re: PROPOSAL: Host and support nightly Aurora builds on Apache servers

16 at 12:18 PM, John Sirois <j...@conductant.com> > wrote: > > > > > On Fri, Jan 22, 2016 at 12:59 PM, Bill Farner <wfar...@apache.org> > > wrote: > > > > > > > FWIW we already link to nightlies from > > > > https://aurora.apache.o

Re: [PROPOSAL] Job instance scaling APIs

At risk of devolving the discussion, is it worth calling the method addInstances as opposed to scaleOut? I find the former more descriptive. On Tue, Jan 19, 2016 at 11:12 AM, Maxim Khutornenko wrote: > "Of course, the scaler could manually health check that all instances >

Re: [PROPOSAL] Job instance scaling APIs

m.invalid> > wrote: > > +1 to addInstances > > > > On Tue, Jan 19, 2016 at 3:00 PM, Bill Farner <wfar...@apache.org> wrote: > > > >> At risk of devolving the discussion, is it worth calling the method > >> addInstances as opposed to scaleOut? I f

Re: [PROPOSAL] Job instance scaling APIs

> In the current release we will fork the behavior depending on whether > the InstanceKey is present. In the next release, we drop 1,2 and 3 and > end up with only 4 and 5. > > Any concerns? > > On Tue, Jan 19, 2016 at 3:57 PM, Bill Farner <wfar...@apache.org> wrote: >

Re: Non-exclusive dedicated constraint

Also, regarding dedicated constraints necessitating a slave restart - i've pondered moving dedicated machine management to the scheduler for similar purposes. There's not really much forcing that behavior to be managed with a slave attribute. On Tue, Jan 19, 2016 at 7:05 PM, John Sirois

Re: Non-exclusive dedicated constraint

e hostname 'relevance' > may not work as dedicated hosts may be fully packed and not release > any resources for a very long time. Let me explore this idea a bit to > see what it would take to implement. > > On Tue, Jan 19, 2016 at 8:22 PM, Bill Farner <wfar...@apache.org> wrote: &g

Re: Non-exclusive dedicated constraint

r similar > > purposes. There's not really much forcing that behavior to be managed > with > > a slave attribute. > > > Would you mind giving a few more hints on the mechanics behind this? How > would scheduler know about dedicated hw without the slave attributes set?

Re: Seeking 0.12.0 release manager

Thanks, John! I'll work with you offline to move forward. On Fri, Jan 15, 2016 at 5:55 PM, John Sirois <john.sir...@gmail.com> wrote: > On Thu, Jan 14, 2016 at 8:55 PM, Bill Farner <wfar...@apache.org> wrote: > > > Folks, > > > > As we approach completion of

Multi-role cluster doc

Hey everyone, Now that we've landed the patch below (thanks again, Zhitao!), it dawned on me that we should have a bit of documentation providing guidance for using Aurora in a cluster with other frameworks. Specifically, we should guide users to statically partition their slaves or disable the

Seeking 0.12.0 release manager

Folks, As we approach completion of work for the 0.12.0 release, i would like to identify a release manager. If nobody is able, i am happy to take this on myself. However, i think it's a good process to share if only to advance tooling through additional users. I think it's safe to say that

Re: [PROPOSAL] Amend 0.12.0 release goals

Thanks for all the input folks, i have made these changes in jira. On Thu, Jan 14, 2016 at 10:23 PM, Jake Farrell <jfarr...@apache.org> wrote: > sounds good, +1 > > -Jake > > On Thu, Jan 14, 2016 at 10:02 AM, Bill Farner <wfar...@apache.org> wrote: > > > Give

Re: [PROPOSAL] Job instance scaling APIs

How is scaling down different from killing instances? On Thursday, January 14, 2016, Joshua Cohen wrote: > What happens if a job has been scaled out, but the underlying config is not > updated to take that scaling into account? Would the next update on that > job revert the

Re: [PROPOSAL] Job instance scaling APIs

Fwiw I think an APi call being "too powerful" is not a good reason to introduce another. As for the specific behavior here, I know there has been a desire to eliminate the use of TaskQuery in killTasks because it is rarely used, and kills spanning jobs can be implemented on top of the APi. On

[PROPOSAL] Amend 0.12.0 release goals

Given that we are still playing catch-up to mesos releases (we are on 0.25.0, latest is 0.26.0, there's talk of cutting 0.27.0 soon), i would like to suggest that we remove these tickets from 0.12.0: https://issues.apache.org/jira/browse/AURORA-987

Re: Parameterize each Job Instance.

:02 PM, John Sirois <john.sir...@gmail.com> > > wrote: > > > > > > > > > > > On Mon, Jan 11, 2016 at 11:00 PM, Bill Farner <wfar...@apache.org> > > wrote: > > > > > >> In the log, tasks are denormalized anyhow: > >

New committer and PMC member: Steve Niemitz

Folks, Please join me in welcoming Steve Niemitz, who is now an Aurora committer and PMC member! Steve has been active in the community for over a year, initially contributing by championing and implementing Docker support in Aurora. Welcome aboard, Steve!

Re: Parameterize each Job Instance.

uration-reference/#template-namespaces > > On Mon, Jan 11, 2016 at 8:05 PM Bill Farner <wfar...@apache.org> wrote: > > > 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 > &

Re: [PROPOSAL] Replace commons-args

uot; - you mastered > the original library and I fully trust you with the new one :) > > +1. > > On Thu, Jan 7, 2016 at 6:58 PM, Bill Farner <wfar...@apache.org> wrote: > > Can you turn that concern into a more firm stance? > > > > FWIW if you look closely, there's

  1   2   >