[ 
https://issues.apache.org/jira/browse/SAMZA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936809#comment-15936809
 ] 

Navina Ramesh commented on SAMZA-1120:
--------------------------------------

[~jmakes] Well-written summary! 
One QQ: Wouldn't all new samza applications, irrespective of whether written 
with fluent-api or low-level api deploy as "Application"? 

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

Reply via email to