[ https://issues.apache.org/jira/browse/SAMZA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937077#comment-15937077 ]
Jake Maes commented on SAMZA-1120: ---------------------------------- [~navina] yes, all *new* applications will. There's nothing preventing a seasoned samza user from starting a new application as a job rather than an application (by running run-job.sh rather than run-app.sh and skipping the extra app.* properties) but that's really not worth calling out. So, I'll fix the phrasing above. Thanks! > 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)