Jenkins build is back to normal : Aurora #774

2014-12-02 Thread Apache Jenkins Server
See

Re: aurora watch_secs change

2014-12-02 Thread Brian Wickman
Refactoring the executor to allow (B) is also probably easiest, but per Farner's caveat -- it should only send framework messages on status transitions. There is something called the StatusManager that takes in input from any status checker (such as the health checker, announcer, resource manager,

Re: aurora watch_secs change

2014-12-02 Thread Bill Farner
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

aurora watch_secs change

2014-12-02 Thread Nakamura
Howdy, I'm interested in tackling AURORA-894, but I'm not terribly familiar with aurora, so I'd like some feedback on my design before I go forth. Bill pointed out that the hard bit would be designing the algorithm so it doesn't DDoS the scheduler, and I think I have an idea of the possible desig

Build failed in Jenkins: Aurora #773

2014-12-02 Thread Apache Jenkins Server
See Changes: [kevints] Modify TRequestsTransport to raise an exception 4xx or 5xx responses. [kevints] Improve unbounded ref exception. -- [...truncated 2565 lines...] Downloading/unpacking twitter.commo

Jenkins build is back to normal : Aurora #772

2014-12-02 Thread Apache Jenkins Server
See

Build failed in Jenkins: Aurora #771

2014-12-02 Thread Apache Jenkins Server
See Changes: [kevints] Don't intercept methods on thrift that don't return Response. -- [...truncated 2565 lines...] Downloading/unpacking twitter.common.collections==0.3.1 (from -r

Build failed in Jenkins: Aurora #770

2014-12-02 Thread Apache Jenkins Server
See Changes: [wfarner] Fix some URLs and text in release emails to include "-incubating" where appropriate. -- [...truncated 2598 lines...] Downloading/unpacking twitter.common.options==0.3.1 (from -

Re: override python interpreter when building pex using pants

2014-12-02 Thread Kevin Sweeney
I don't believe this is possible until https://issues.apache.org/jira/browse/AURORA-358 is complete. On Tue, Dec 2, 2014 at 10:23 AM, Brian Wickman wrote: > You can use ./pants build -i to build with a > specific interpreter, but it will still revert to a #!/usr/bin/env > pythonX.X hashbang li

Re: override python interpreter when building pex using pants

2014-12-02 Thread Brian Wickman
You can use ./pants build -i to build with a specific interpreter, but it will still revert to a #!/usr/bin/env pythonX.X hashbang line. There is not yet a pants environment variable to switch interpreters at runtime but it would be a straightforward feature to add. I've filed https://github.co

override python interpreter when building pex using pants

2014-12-02 Thread Bhuvan Arumugam
It's more of pants/pex question. I've installed python2.7 in a custom path. I want to build aurora_client using this interpreter. By default, it use python2.7 in the PATH (#!/usr/bin/env python2.7). How do I change it to use python2.7 in custom path? pex support this feature with --interpreter opt