ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Onischuk (JIRA)" <>
Subject [jira] [Created] (AMBARI-3924) Resource management framework: resources should be executed immediately
Date Thu, 28 Nov 2013 20:10:35 GMT
Andrew Onischuk created AMBARI-3924:

             Summary: Resource management framework: resources should be executed immediately
                 Key: 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 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.
- 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

View raw message