Re: shutdown vs kill API is Mesos

The HTTP API is what is used under the hood for V0 and V1 (instead of libmesos), I believe that's what David was referencing when he mentioned the HTTP performance issues. Here's a better explanation from the original patch submitted by Zameer:

Re: shutdown vs kill API is Mesos

Right. In order to keep the current abstraction in Aurora (both APIs), we obviously have to bind to the lower common denominator API methods. So the only way to integrate with shutdown will be to fix the performance issues so we can switch to the new API. The performance issue we ran into at

Re: shutdown vs kill API is Mesos

Sorry, the other approach outlined by Bill would in theory work too, but it sounds like in practice it also needs more changes on the Mesos side. On Thu, Jan 11, 2018 at 1:55 PM, David McLaughlin wrote: > Right. In order to keep the current abstraction in Aurora (both

Re: shutdown vs kill API is Mesos

Sorry, I guess referring to it as the libmesos way of talking to the Mesos master is a bit misleading. And I stand corrected, the V0 is only an adaptor to the V1 interface which still uses the undocumented RPC way of talking to the master (

Re: shutdown vs kill API is Mesos

David, - LCD makes sense. Does that mean that Twitter is using the SCHEDULER_DRIVER version? - I don't see Bill's proposal on this

Re: shutdown vs kill API is Mesos

https://github.com/apache/aurora/blob/aae2b0dc73b7534c66982ed07b1f029150e245de/src/main/java/org/apache/aurora/scheduler/mesos/SchedulerDriverModule.java

Re: shutdown vs kill API is Mesos

Thanks Renan. I saw that code. "Driver" interface does not have SHUTDOWN...so it is not "compatible". I was trying to change to VersionedSchedulerDriverService all over the code (that wreaks havoc across the tests!) but Mesos's Java wrapper