[
https://issues.apache.org/jira/browse/AMBARI-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-3924:
------------------------------------
Attachment: AMBARI-3924.patch
> Resource management framework: resources should be executed immediately
> -----------------------------------------------------------------------
>
> Key: AMBARI-3924
> URL: https://issues.apache.org/jira/browse/AMBARI-3924
> Project: Ambari
> Issue Type: Bug
> Reporter: Andrew Onischuk
> Assignee: Andrew Onischuk
> Fix For: 1.5.0
>
> Attachments: AMBARI-3924.patch
>
>
> Currently, RMF acts like puppet. All scripts are executed in 2 stages:
> 1) Interpretation: All variables, "if" and "switch" statements are resolved
> and a list of resources is created
> 2) Execution: All resources are actually created/executed/modified in
> asynchronous (puppet) or sequential (RMF) way
> This approach is great because a system will be never left half-configured
> because of undefined variable: interpretation step will fail, and execution
> will not start.
> Also, such approach is great for unit testing (we may check resource
> definitions, staged for execution, without actually executing them)
> But for our usage, such delayed execution produces few troubles:
> - Due to delayed execution, we can not check results of command execution at
> our python logic. For example, we can not check if a file contains some text
> after we run Exec() statement. Of course, we may add yet another Exec()
> statement with shell code, but it's a hack. Solution may look like adding a
> callback function to Exec() resource syntax, but that affects simplicity and
> usability.
> - due to a previous reason, writing service status checks for services is
> hard. Especially if "service <name> status" command does not return non zero
> exit code when service is not running.
> - Using debugger for python scripts is not trivial as we don't see results of
> command execution immediately and have to dive into env.run() essentials.
> h3. The proposal is:
> - Resources should execute immediately after definition. Any issues like
> undefined variables will be cached during development/QA testing and should
> not appear at production clusters.
> - env.run() call is not necessary now
> - To preserve unit testing advantages, Environment constructor should accept
> optional parameter "test_mode" (that defaults to false). If this parameter is
> set to true, than resources are not executed, but are still added to internal
> list inside Environment
> - Other architecture details should remain as is (resources are defined and
> executed within Environment context, list of defined resources is stored
> inside Environment)
> h3. Expected impact:
> - Existing scripts for services probably will not require modifications (they
> are ported from puppet that uses the same paradigm). In some cases, they may
> be simplified.
> - Custom command implementations and status check methods will be simpler
> - RMF learning curve should become more flat
--
This message was sent by Atlassian JIRA
(v6.1#6144)
