[
https://issues.apache.org/jira/browse/SAMZA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937102#comment-15937102
]
Navina Ramesh commented on SAMZA-1120:
--------------------------------------
Ok. Thanks for explaining. [~xinyu] had given me an impression that we will
eventually deprecate the run-job path and everyone will switch to run-app.sh.
Perhaps we can clarify with him on this once he completes his proposal -
[SEP-2|https://cwiki.apache.org/confluence/display/SAMZA/SEP-2%3A+ApplicationRunner+Design]
> Config scope changes for multi-stage
> ------------------------------------
>
> Key: SAMZA-1120
> URL: https://issues.apache.org/jira/browse/SAMZA-1120
> Project: Samza
> Issue Type: Bug
> Affects Versions: 0.13.0
> Reporter: Jake Maes
> Assignee: Jake Maes
>
> With the multi-stage feature (SAMZA-1041), Samza will have the ability to run
> a collection of processors as a unit. To configure those processors with a
> single config, we need a way to independently configure each processor.
> The current best idea is to introduce a new scope in the configs. Here are 2
> options that differ only in naming.
> 1. Application->Job->Task scopes for configs. Application configs apply to
> the entire multistage application. A job config corresponds to a particular
> processor or job in the application and a task config applies to a particular
> task.
> 2. Job->Processor->Task scopes for configs. In this model, a Job is the
> deployable unit and corresponds to the full multistage application. A
> processor is an independent stage in the application.
> The advantage of #1 is most developers seem to prefer the term "Application"
> over "Job"
> The advantage of #2 is minimal renaming in the code and configs, which will
> likely make migration easier.
> In both cases, we could define an inheritance structure s.t. any config not
> defined at the processor scope can be inherited from the application scope.
> This should reduce the verbosity of the configs.
> btw. this is an issue that app.runner config with job.factory.class config.
> Do we allow configuring job.factory.class in different runner mode? If so,
> what are the options?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
