mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Qian Zhang <zhang...@cn.ibm.com>
Subject Re: Review Request 44424: Updated http_command_executor.cpp to use v1 API.
Date Sun, 03 Apr 2016 12:49:16 GMT


> On March 8, 2016, 8:08 a.m., Anand Mazumdar wrote:
> > src/launcher/http_command_executor.cpp, line 105
> > <https://reviews.apache.org/r/44424/diff/2/?file=1282127#file1282127line105>
> >
> >     Why did you move this? Let's have the ordering of member variables the same
as command executor.
> >     
> >     Also thanks for resolving the ambiguity name in the name of `override` variable.
I would love it that you make a similar change to the command executor code too.

Posted a patch for updating command executor: https://reviews.apache.org/r/45623/


> On March 8, 2016, 8:08 a.m., Anand Mazumdar wrote:
> > src/launcher/http_command_executor.cpp, line 120
> > <https://reviews.apache.org/r/44424/diff/2/?file=1282127#file1282127line120>
> >
> >     Let's scope all the functions after this to the `protected` namespace. 
> >     
> >     I know that you had an initial look into the example code that has them in the
`public` namespace. But, most of them are generally meant to be used as simple walkthrough
code-samples.

Can you please elaborate why making those methods (`connected()`, `doReliableRegistration()`,
`disconnected()`, `received()`, etc.) protected? I see command executor have the similar methods
(`registered()`, `reregistered()`, `disconnected()`, `launchTask()`, etc.) as public too.


> On March 8, 2016, 8:08 a.m., Anand Mazumdar wrote:
> > src/launcher/http_command_executor.cpp, line 244
> > <https://reviews.apache.org/r/44424/diff/2/?file=1282127#file1282127line244>
> >
> >     New line here. I am assuming you won't need it when you move this to an helper
function.

Can you please elaborate why we do not need it when I move the code to launch task into the
helper method `launchTask()`?


> On March 8, 2016, 8:08 a.m., Anand Mazumdar wrote:
> > src/launcher/http_command_executor.cpp, lines 930-931
> > <https://reviews.apache.org/r/44424/diff/2/?file=1282127#file1282127line930>
> >
> >     s/unAckedUpdates/updates
> >     s/unAckedTask/task
> >     
> >     Did you think naming it as `task` might result in ambiguity?

Yeah, there is already a local variable `task` in the code to launch task: `const TaskInfo&
task = event.launch().task();`, maybe we rename this local variable to `_task` to avoid ambiguity?


> On March 8, 2016, 8:08 a.m., Anand Mazumdar wrote:
> > include/mesos/v1/mesos.proto, lines 1796-1813
> > <https://reviews.apache.org/r/44424/diff/2/?file=1282126#file1282126line1796>
> >
> >     hmmm .. Did you test if the health check workflow works?
> >     
> >     IIUC, the `mesos-health-check` binary sends a `TaskHealthStatus` message back
to the executor and that message is not of type `v1::TaskHealthStatus`. If we try to deserialize,
it should fail at that point. 
> >     
> >     For now, it seems to me that the best course of action is to preserve/keep using
the unversioned health check binary/message. In future, we might want to either modify the
existing `mesos-health-check` binary to emit `v1::TaskHealthStatus` messages in addition to
the unversioned ones or create a new binary for versioned health checks. I would recommend
filing a JIRA and a TODO in the code mentioning this. Makes sense?

Thanks for the comment! I think `TaskHealthStatus` and `v1:: TaskHealthStatus` have exactly
same fields, so it should be OK to do serialize/deserialize between them, right? Actually
all the Call messages sent by this HTTP command executor are v1, and agent is always trying
to receive non-v1 messages, I see there is no issues between them.


- Qian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44424/#review122377
-----------------------------------------------------------


On March 6, 2016, 5:08 p.m., Qian Zhang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44424/
> -----------------------------------------------------------
> 
> (Updated March 6, 2016, 5:08 p.m.)
> 
> 
> Review request for mesos, Anand Mazumdar and Vinod Kone.
> 
> 
> Bugs: MESOS-3558
>     https://issues.apache.org/jira/browse/MESOS-3558
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Updated http_command_executor.cpp to use v1 API.
> 
> 
> Diffs
> -----
> 
>   include/mesos/v1/mesos.proto 31960a52061f70d80528fb8326522ae1d6f75b2c 
>   src/launcher/http_command_executor.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/44424/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message