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: [proposal] Deprecate the Thermos CLI

One thing I would like to point out is the thermos CLI is not required for Aurora operation. I think we would be better served by advertising it as an optional component that provides operators and users with debugging ability. On Tue, Feb 17, 2015 at 6:38 PM, Joseph Smith wrote: > I believe it

Re: [proposal] Deprecate the Thermos CLI

I believe it absolutely is- ideally as we deprecate the Observer, we can then lean on the Mesos Slave for this information instead. This will further decrease the number of moving pieces, simplifying the operation of an Aurora/Mesos cluster. > On Feb 17, 2015, at 6:33 PM, Zameer Manji wrote: >

Re: [proposal] Deprecate the Thermos CLI

Joe, If I understand Brian's proposal correctly < http://mail-archives.apache.org/mod_mbox/aurora-dev/201501.mbox/%3CCAFTdr0DZvH21tR=NLK0qP-Y9-oL9SyULy6GLah=capuw0sv...@mail.gmail.com%3E>, we are going to depreciate the Observer. This combined with your proposal will make the executor the only com

[proposal] Deprecate the Thermos CLI

Hi everyone, After reviewing the functionality offered by the Thermos Commandline tool vs. what’s exported via the Thermos Observer, I was hoping to bring up a question I had: Can we deprecate the Thermos CLI? Removing this would decrease the number of components required for a functional Aur

Jenkins build is back to normal : AuroraBot #3614

See

Jenkins build is back to normal : Aurora #886

See

Build failed in Jenkins: Aurora #885

See Changes: [jcohen] Update jenkins build script to run python tests in verbose mode. -- [...truncated 2305 lines...] Building C (GLib) Library : no Building Java Library : no Building C# Li

Build failed in Jenkins: Aurora #884

See Changes: [wickman] Update aurora to commons 0.3.3, unflake tests using ThreadedClock -- [...truncated 2305 lines...] Building C (GLib) Library : no Building Java Library : no Building C#

Build failed in Jenkins: Aurora #883

See Changes: [zmanji] Pin protobuf dependency to 2.6.1 [kevints] Extract ReadOnlyScheduler to its own implementation class and delegate [wfarner] Enable checkstyle indentation check, fix violations. -- [

Build failed in Jenkins: AuroraBot #3611

See Changes: [wfarner] Fix build break - remove unused imports. -- [...truncated 3770 lines...]  src/test/python/apache/aurora/client/cli/test_update.py .

Re: Aurora.pex client can't find scheduler

Is there a reason you set zk_in_proc=true? Setting it tells the scheduler to ignore the "real" ZK server and use an in-proc one instead. -zk_in_proc=false Launches an embedded zookeeper server for local testing causing -zk_endpoints to be ignored if specified. (com.twitter.common.zookeeper.guice.

Aurora.pex client can't find scheduler

Hello. I'm bump in into following problems when trying to perform the very first 'aurora.pex job create' command. 1) 'Could not connect to scheduler: No schedulers detected in devcluster' and 2) 'Failed to connect to Zookeeper within 10 seconds.' It had tried to check everything in configurations

Jenkins build is back to normal : Aurora #882

See

Re: Build issues: Thermos executor not working

I'm picking this up. I have filed https://issues.apache.org/jira/browse/AURORA-1128 to track my progress in this issue. On Tue, Feb 17, 2015 at 9:40 AM, Kevin Sweeney wrote: > You'll also need to add the dependency everywhere that depends on > 3rdparty/python:mesos.interface. > > On Tue, Feb 17,

Re: Apache Aurora meet up in San Francisco, Feb 19th

A quick reminder, an Apache Aurora meetup is taking place on Thursday starting at 6pm. Hope you can make it! We already have over 100 folks registered. You can register here: https://www.eventbrite.com/e/apache-aurora-meet-up-tickets-15618171371 And yes, we'll post videos from the event -- but w

Summary of IRC Meeting in #aurora

Summary of IRC Meeting in #aurora at Tue Feb 17 19:03:01 2015: Attendees: thalin, wickman, jfarrell, jcohen, wfarner, kts, mkhutornenko, zmanji, Floomi, t3hSteve, dlester - Preface - Graduation - Action: jfarrell will start a community vote towards graduation from the Apache Incubator - 0.8.0

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

I need to run on Ubuntu 12.04 (Cant upgrade to 14.04). I built my own mesos.native egg within an Ubuntu 12.04 VM and put in the third_party directory when building thermos but after starting a job, I get this in the Mesos log ImportError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.16' not f

Build failed in Jenkins: AuroraBot #3610

See -- [...truncated 3759 lines...]  src/test/python/apache/aurora/client/cli/test_update.py . generated xm

Re: Build issues: Thermos executor not working

You'll also need to add the dependency everywhere that depends on 3rdparty/python:mesos.interface. On Tue, Feb 17, 2015 at 9:39 AM, Kevin Sweeney wrote: > I ran into this issue as well - it looks like the problem is that Mesos > requires protobuf<3, which 3.0.0-alpha1 technically is (pants uses

Re: Build issues: Thermos executor not working

I ran into this issue as well - it looks like the problem is that Mesos requires protobuf<3, which 3.0.0-alpha1 technically is (pants uses a different resolver than pip - pip will ignore alpha versions unless run with --pre). A workaround is to add an explicit dependency on protobuf==2.6.1 to our 3

Re: reasonable preemption delay to use

The watch_secs is triggered when a task enters RUNNING. In order for the rolling update to not fail early the restart_threshold [1] needs to be bumped up to account for the preemption delay. As for the default preemption delay, it was implemented to avoid unnecessary churn in the cluster. Larger/c

Build failed in Jenkins: AuroraBot #3609

See -- [...truncated 3759 lines...]  src/test/python/apache/aurora/client/cli/test_update.py . generated xm

Build failed in Jenkins: AuroraBot #3608

See -- [...truncated 3764 lines...]  src/test/python/apache/aurora/client/cli/test_update.py . generated xm

Build failed in Jenkins: AuroraBot #3607

See -- [...truncated 3759 lines...]  src/test/python/apache/aurora/client/cli/test_update.py . generated xm

Build failed in Jenkins: AuroraBot #3606

See -- [...truncated 3763 lines...]  src/test/python/apache/aurora/client/cli/test_update.py . generated xm

Build issues: Thermos executor not working

Hi everyone, we try to build the latest Aurora git version on a Debian 7 host. Unfortunately, the resulting executor seems to be broken, as it fails to start with the following message: WARNING: Logging before InitGoogleLogging() is written to STDERR I0216 18:16:51.178513 25237 fetcher.cpp:76]

Re: reasonable preemption delay to use

If I remember correctly, you also have to make sure that your UpdateConfig watch_secs is larger than your preemption_delay. Otherwise a rolling update of a production job might not be able to get the resources it needs. Best Regards, Stephan From: Bhuvan

Build failed in Jenkins: AuroraBot #3605

See -- [...truncated 3754 lines...]  src/test/python/apache/aurora/client/cli/test_update.py . generated xm