You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Sumit Mohanty (JIRA)" <ji...@apache.org> on 2016/05/20 03:30:13 UTC
[jira] [Updated] (AMBARI-16222) Improve blueprint based deploy
speed with GroupedCommandExecutor
[ https://issues.apache.org/jira/browse/AMBARI-16222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sumit Mohanty updated AMBARI-16222:
-----------------------------------
Description:
- Implement a GroupedCommand Executer that is able to execute a uber command.json that describe how to Start / Stop *all host-components* on a host.
- This generated command.json describes a *stage* in it entirety with all the commandParms list that need to be executed.
- The GCE launches CONFIGURE actions serially
- The Start/Stop operations are launched in parallel with retires
- Consider launching single python process for executing the operations as a cost saver for CONFIGURE operations
*Note*: We still restrict this to a stage to simplify things like RCO which are not understood on the agent-side. The blueprints deploys already limit number of stages created and thereby sticking to a stage as logical separation between GroupedCommands make sense for now.
was:
- Implement a GroupedCommand Executer that is able to execute a uber command.json that describe how to Start / Stop *all host-components* on a host.
- This generated command.json describes a *stage* in it entirety with all the commandParms list that need to be executed.
- The GCE launches CONFIGURE actions serially
- The Start/Stop operations are launched in parallel with retires
- Consider launching single python process for executing the operations as a cost saver for CONFIGURE operations
*Note*: We still restrict this to a stage to simplify things like RCO which are not understood on the agent-side. The blueprints deploys for MSFT already limit number of stages created and thereby sticking to a stage as logical separation between GroupedCommands make sense for now.
> Improve blueprint based deploy speed with GroupedCommandExecutor
> ----------------------------------------------------------------
>
> Key: AMBARI-16222
> URL: https://issues.apache.org/jira/browse/AMBARI-16222
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
> Reporter: Sebastian Toader
> Assignee: Andrew Onischuk
> Fix For: 2.4.1
>
>
> - Implement a GroupedCommand Executer that is able to execute a uber command.json that describe how to Start / Stop *all host-components* on a host.
> - This generated command.json describes a *stage* in it entirety with all the commandParms list that need to be executed.
> - The GCE launches CONFIGURE actions serially
> - The Start/Stop operations are launched in parallel with retires
> - Consider launching single python process for executing the operations as a cost saver for CONFIGURE operations
> *Note*: We still restrict this to a stage to simplify things like RCO which are not understood on the agent-side. The blueprints deploys already limit number of stages created and thereby sticking to a stage as logical separation between GroupedCommands make sense for now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)