>
> We still need "Agent ID" for the shutdown call.
Darn. In that case, how about we change the method signature in Driver to
accept agentId and ignore that param in MesosSchedulerDriver.
But do we really need the command line option?
Aurora can run tasks without an executor. I'm assuming the shutdown call
is incompatible with that mode.
On Tue, Jan 16, 2018 at 1:57 PM, Mohit Jaggi <mohit.ja...@uber.com> wrote:
> We still need "Agent ID" for the shutdown call.
>
> On Tue, Jan 16, 2018 at 1:57 PM, Mohit Jaggi <mohit.ja...@uber.com> wrote:
>
>> Sounds good. But do we really need the command line option? One can use
>> an older Driver if KILL is preferred for some reason.
>>
>> On Tue, Jan 16, 2018 at 1:51 PM, Bill Farner <wfar...@apache.org> wrote:
>>
>>> This situation is much simpler if task ID == executor ID. I can't come
>>> up with a good reason why this is not the case today. Our executor IDs
>>> originally included static prefix, though i do not recall any rationale for
>>> this. When Renan added custom executor support, this static prefix was
>>> made configurable. Again, i do not believe there was any rationale for the
>>> utility of executor IDs.
>>>
>>> I propose the following:
>>> - Change relevant code in MesosTaskFactory to
>>> setExecutorId(task.getTaskId())
>>> - Add a command line parameter (default false) to toggle use of executor
>>> shutdown in VersionedSchedulerDriverService.killTask
>>>
>>> Does anyone see an issue with this approach?
>>>
>>> On Tue, Jan 16, 2018 at 11:15 AM, Mohit Jaggi <mohit.ja...@uber.com>
>>> wrote:
>>>
>>>> To do this in a backward compatible manner, one way is :
>>>>
>>>> ```
>>>> void destroy(taskId, executorId, agentId) {
>>>>
>>>> if(driver instanceOf Versioned....)
>>>> (Versioned...)driver.shutdown(executorId, agentId)
>>>> else
>>>> driver.kill(taskId)
>>>>
>>>> }
>>>> ```
>>>>
>>>> Any other opinions?
>>>>
>>>> On Tue, Jan 16, 2018 at 11:12 AM, David McLaughlin <
>>>> dmclaugh...@apache.org> wrote:
>>>>
>>>>> Nope, I support getting SHUTDOWN in for users of the new API.
>>>>>
>>>>> On Tue, Jan 16, 2018 at 11:06 AM, Mohit Jaggi <mohit.ja...@uber.com>
>>>>> wrote:
>>>>>
>>>>>> Are you suggesting that we delay the switch to SHUTDOWN call until
>>>>>> this working group can resolve the API perf issue?
>>>>>>
>>>>>> On Mon, Jan 15, 2018 at 3:55 PM, David McLaughlin <
>>>>>> dmclaugh...@apache.org> wrote:
>>>>>>
>>>>>>> We are working with Mesos folks to resolve it. There is a Mesos
>>>>>>> performance working group that folks can join if they'd like to
>>>>>>> contribute:
>>>>>>> http://mesos.apache.org/blog/performance-working-group-progr
>>>>>>> ess-report/
>>>>>>>
>>>>>>> I'm not sure what you mean by branch. Everything we used to scale
>>>>>>> test is on master.
>>>>>>>
>>>>>>> On Mon, Jan 15, 2018 at 10:08 AM, Meghdoot bhattacharya <
>>>>>>> meghdoo...@yahoo.com> wrote:
>>>>>>>
>>>>>>>> David, should twitter try against mesos 1.5 to see if things are
>>>>>>>> better with the new api instead of libmesos. This is going to be a
>>>>>>>> drift
>>>>>>>> over time that will stop us from adopting new features.
>>>>>>>>
>>>>>>>> If it was sometime back it would be good to rerun the tests and
>>>>>>>> open a ticket in Mesos if issues exist. All aurora users can then push
>>>>>>>> for
>>>>>>>> resolution.
>>>>>>>>
>>>>>>>> Also details on branch etc that has the api integration?
>>>>>>>>
>>>>>>>> Thx
>>>>>>>>
>>>>>>>> On Jan 12, 2018, at 11:39 AM, David McLaughlin <
>>>>>>>> dmclaugh...@apache.org> wrote:
>>>>>>>>
>>>>>>>> I'm not sure I agree with the summary. Bill's proposal was using
>>>>>>>> shutdown only when using the new API. I would also support this if it's
>>>>>>>> possible.
>>>>>>>>
>>>>>>>> On Fri, Jan 12, 2018 at 11:14 AM, Mohit Jaggi <mohit.ja...@uber.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Summary so far:
>>>>>>>>> - Bill supports making this change
>>>>>>>>> - This change cannot be made in a backward compatible manner
>>>>>>>>> - David (Twitter) does not want to use HTTP APIs due to
>>>>>>>>> performance concerns. I conclude that folks from Twitter don't
>>>>>>>>> support this
>>>>>>>>> change
>>>>>>>>>
>>>>>>>>> Question:
>>>>>>>>> - Are there other users that want this change?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
