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