> 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
> 
>

Reply via email to