[
https://issues.apache.org/jira/browse/AMBARI-15417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197435#comment-15197435
]
Robert Nettleton commented on AMBARI-15417:
-------------------------------------------
[~bhuvnesh2703], Its not clear if there is an easy path towards enabling the
flag that is described in this JIRA.
I was not the architect behind this implementation change in Blueprints, but
the change in Ambari 2.1.0 was quite extensive, and there is no clear way to
provide the older behavior.
This means that supporting Role Command Ordering (to simulate the Ambari
Blueprints behavior prior to Ambari 2.1.0 in Blueprints could require a major
refactoring that would be quite a large task.
The dynamic provisioning model in Blueprints introduced in Ambari 2.1.0 does
introduce many performance and scaling benefits. Starting a large cluster is
now much more fault-tolerant, since a given node failure will not cause the
entire cluster deployment to fail. This turns out to be quite important when
clusters are large.
I would propose that a lightweight orchestrator be introduced into Ambari
Blueprints, that would support some level of configurable dependency ordering
without sacrificing the gains achieved in Ambari 2.1.0 that are listed above.
Unfortunately, that is probably not a small amount of work, but could possibly
provide a reasonable balance between the ordering guarantees of the older model
and the performance gains of the model introduced in 2.1.0.
CC [~sumitmohanty], [~mahadev], [~jspeidel]
> 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)
