[
https://issues.apache.org/jira/browse/SAMZA-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620358#comment-14620358
]
Gustavo Anatoly commented on SAMZA-680:
---------------------------------------
I agree with you is a good decision :). I'm also waiting where the discussions
goes.
> Invert the JobCoordinator and AM logic
> --------------------------------------
>
> Key: SAMZA-680
> URL: https://issues.apache.org/jira/browse/SAMZA-680
> Project: Samza
> Issue Type: Improvement
> Reporter: Naveen Somasundaram
> Assignee: Gustavo Anatoly
>
> Currently, the YARN AM pretty much dictates how the JobCoordinator works.
> This creates lot of inflexibility on how we can control failures or even
> integrate with new system (Mesos).
> For e.g.,
> https://issues.apache.org/jira/browse/SAMZA-465?focusedCommentId=14522043&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14522043
> It would nice to invert the logic to JobCoordinator, and JobCoordinator has a
> global view of container failures, config changes etc. This simplifies lot of
> implementation specifics (for e.g., dynamic scaling becomes easier).
> A another nice to have, would be make this logic pluggable.
> {noformat}
> e.g.,
> jobcoordinator.core=com.linkedin.YarnJobCoordinator
> or
> jobcoordinator.core=com.linkedin.MesosJobCoordinator
> or
> jobcoordinator.core=com.linkedin.SomeCustomJobCoordinator
> {noformat}
> It would be nice for users who operate it as a service, to inject their own
> logic (e.g., Users extending, say, YanJobCoordinator to their own custom
> class and do some special logging/actions before container failure)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
