[
https://issues.apache.org/jira/browse/OOZIE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270020#comment-14270020
]
Robert Kanter commented on OOZIE-2107:
--------------------------------------
The difficulty with that is that if you have
{{oozie.service.SchemaService.wf.ext.schemas}} set to ssh, sqoop, etc in
oozie-default, and the user wants to add a custom schema, they have to include
the ssh, sqoop, etc schemas. And if they upgrade to a new Oozie release that
has new schemas, they have to be aware of this and update their oozie-site to
add the new schemas; which is one of the things we wanted to fix when we moved
everything to oozie-default.
Though I understand that with this setup, removing schemas is a more difficult.
Any ideas on how to easily allow adding and removing schemas without having to
redefine the existing schemas? I haven't been able to come up with a solution
that works for both.
> Schema config properties should be consistent with ActionExecutor config
> properties
> -----------------------------------------------------------------------------------
>
> Key: OOZIE-2107
> URL: https://issues.apache.org/jira/browse/OOZIE-2107
> Project: Oozie
> Issue Type: Improvement
> Components: core
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-2107.patch
>
>
> For specifying ActionExecutors, we have
> {{oozie.service.ActionService.executor.classes}} and
> {{oozie.service.ActionService.executor.ext.classes}}. The former specifies
> the default ones, and the latter allows adding/overriding them.
> For specifying the corresponding action schemas, we have just:
> {{oozie.service.SchemaService.wf.ext.schemas}}. This makes it difficult for
> users to add/override schemas. We should add a
> {{oozie.service.SchemaService.wf.schemas}} with the default schemas, where
> the "ext" config would add/override. This should be backwards compatible
> because both properties get loaded. We can also remove the workflow schemas
> from being hardcoded in the SchemaService class.
> Similarly, we should do the same for the coordinators, bundles, and sla
> schema properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
