[
https://issues.apache.org/jira/browse/AMBARI-15417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194671#comment-15194671
]
jun aoki commented on AMBARI-15417:
-----------------------------------
I don't have a background knowledge of why RCO is only honored through Wizard,
but would like to chip in my idea.
The service dependencies (RCO) should be always honored regardless of user
input type (Through Wizard, or Blueprint, or even some other means in future)
because it should be simply a part of stack definition.
So I'd like to downvote to introduce a flag to control whether or not RCO is
used.
> 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)
