[
https://issues.apache.org/jira/browse/GRIFFIN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651295#comment-16651295
]
Nikolay Sokolov commented on GRIFFIN-200:
-----------------------------------------
[~toyboxman] looks like there is slight confusion about what kind of events
this ticket is about. I'm talking here specifically about BatchJob/StreamingJob
entities and their lifecycle, not JobInstanceBean. For example, when new job is
created by POST /api/v1/jobs/, or disabled, or deleted. Idea here is to provide
mechanism to extend Griffin's behavior without forking it. For example:
* creating dashboards and/or alerts in third-party system (Grafana, Elastalert)
* disabling alerts in third-party system if job is paused
* validating naming conventions on the jobs
* validating cron schedules (whether job is scheduled "not too frequently")
* RBAC implementation (Hive-style, as plugin)
Note that some of these use cases would need multiple listeners (to have
multiple listeners for multiple features at the same time), as well would
assume listeners to be synchronous (in a sense that handling is happening in
same thread, and can interrupt execution of operation). Good thing about
synchronous interface is that it allows listeners to have asynchronous behavior
internally, if required (have internal queueing, etc). On other hand
asynchronous semantics (let say, separate thread pool handling events) is not
possible to make behaving synchronously.
> Lifecycle hooks support
> -----------------------
>
> Key: GRIFFIN-200
> URL: https://issues.apache.org/jira/browse/GRIFFIN-200
> Project: Griffin (Incubating)
> Issue Type: New Feature
> Reporter: Nikolay Sokolov
> Assignee: William Guo
> Priority: Minor
>
> In some environments, users might want to perform certain actions
> before/after job is created, before/after job is activated, before/after job
> is deleted, and so on.
> To fullfill that need, some hook plugin mechanism can be provided, similar to
> what Hive is doing. User would place respective jar files into Service module
> classpath at deployment time, and would specify class names using some
> annotation or using property listing class names (particular mechanism is yet
> to be determined).
> Proposed signature:
> {code:none}
> public interface JobLifecycleHook {
> void onJobEvent(JobLifecycleEvent event) throws Exception;
> }
> public class BeforeJobCreated implements JobLifecycleEvent { ... }
> public class AfterJobCreated implements JobLifecycleEvent { ... }
> public class BeforeJobDeleted implements JobLifecycleEvent { ... }
> public class AfterJobDeleted implements JobLifecycleEvent { ... }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
