You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Dmitry Lysnichenko (JIRA)" <ji...@apache.org> on 2013/11/28 21:29:35 UTC

[jira] [Commented] (AMBARI-3924) Resource management framework: resources should be executed immediately

    [ https://issues.apache.org/jira/browse/AMBARI-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835066#comment-13835066 ] 

Dmitry Lysnichenko commented on AMBARI-3924:
--------------------------------------------

+1

> 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)