[jira] [Resolved] (AURORA-332) Extend the client plugin architecture to support pre-dispatch and cleanup operations

["Bill Farner (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AURORA-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Farner resolved AURORA-332.
--------------------------------

    Resolution: Fixed

> Extend the client plugin architecture to support pre-dispatch and cleanup operations
> ------------------------------------------------------------------------------------
>
>                 Key: AURORA-332
>                 URL: https://issues.apache.org/jira/browse/AURORA-332
>             Project: Aurora
>          Issue Type: Story
>          Components: Client
>            Reporter: Mark Chu-Carroll
>            Assignee: Mark Chu-Carroll
>             Fix For: 0.5.0
>
>
> (From the proposal shared with the mailing list.)
> The way that configuration plugins work right now in the noun/verb framework is super simple. A configuration plugin is an object with an "execute" method. During command dispatch, after the command parser processes the arguments and a command-appropriate context  is created, the framework iterates over the plugins, and calls the execute method of each one, with the context object and parsed command line parameters.
> There are two problems that I've encountered working with these in practice:
> Some plugins really want to be run before the command-line arguments are processed, and some want to be run after. For example, for a distributed logging system, we'd like to be able to have the logging system optionally enabled before the command is dispatched, so that the dispatch process can use logging. But others, for managing things like proxies, need to be called after arguments are processed, because they rely on arguments.
> Some plugins need cleanups. For example, in logging again, for best performance, we'd like to use multiprocessing to do asynchronous communication with a logserver. But to do that, we need to do a join after the command completes execution. In the current framework, there's no way to do that.
> What I'm thinking about is going more aspect-oriented in the plugins. There will be three points during the execution of a command where plugins can get injected:
> before any argument processing is performed. The only thing that the plugin would be allowed to look at would be the raw, unprocessed command-line parameters. It would return a (potentially) modified copy of the parameters, which would be passed to other plugins, and finally to the actual noun/verb for the command being executed.
> after arguments have been processed, but before the noun/verb is executed. This is exactly what the current plugin "execute" method does.
> after the command has completed executing, but before the client exits.
> The code signatures would be:
>     def beforeDispatch(self, args):
>        """code to execute before dispatching to a noun/verb command.
>         args: a list of the command-line parameters used
>           to invoke aurora.
>         Returns: a possibly modified list of command-line arguments. If this throws an exception, then the execution
>          of the command will be aborted.
>       """
>        
>     def beforeCommand(self, context):
>       """Code to execute after command-line arguments have been
>       processed, but before executing the command. If the
>         code throws a CommandException, then the execution of
>         the command will be aborted.
>       context: the context object that will be used to invoke
>         the command.
>        
>     def cleanupAfterCommand(self, context, returnval):
>        """Code to run after the execution of a noun/verb command has
>        completed, before the command-line application exits.
>        context: the context object that was used to execute the command.
>        returnval: the exit code returned by executing the command.
>       """
> The order of execution of plugins would remain undefined.



--
This message was sent by Atlassian JIRA
(v6.2#6252)