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

bhuvnesh chaudhary commented on AMBARI-15417:
---------------------------------------------

[~jaoki] Currently a retry mechanism is used during cluster deployments using 
blueprint to avoid service startup failures due to incorrect startup order, and 
it was introduced because of some concerns being faced with rco usage. Thus 
preferred keeping both the options, and users can chose whichever suits best to 
their environment.
However, am not sure how not using RCO benefits the performance and dynamic 
scaling. 
I will request [~rnettleton] to help us understand how we achieve the benefit 
by not using rco, probably that will to get to a decision.



> Blueprint should have a flag to allow configuring use of RCO vs Retry method
> ----------------------------------------------------------------------------
>
>                 Key: AMBARI-15417
>                 URL: https://issues.apache.org/jira/browse/AMBARI-15417
>             Project: Ambari
>          Issue Type: Bug
>          Components: blueprints
>    Affects Versions: trunk
>            Reporter: bhuvnesh chaudhary
>
> With Blueprint deploy's, role command oder (RCO) is not honored.
> Currently, in order to mitigate failure for a service start due to 
> dependencies on other services, blueprint deploy uses retry mechanism to 
> ensure that the services are started and their prerequisite are met.
> However, retry mechanism in some cases can cause the install / start time to 
> take long and might need additional logic on component specific installation 
> to handle retries.
> In order to provide with flexibility, we should put up a flag in blueprints 
> which drive the required behavior. (Use RCO vs Use Retry)
> Say: The flag name is use_rco (Change what seems better))
> By default, the value of use_rco can be false and if someone wan't to 
> override it they can specify it as true in the blueprint.
> Note: Keeping it as false by default as it has been already there since 
> Ambari 2.1.0. Hopefully, even if we set this to true by default, it should 
> not impact customers except a few. But we can make this decision based on 
> communities opinion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to