ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bhuvnesh chaudhary (JIRA)" <>
Subject [jira] [Commented] (AMBARI-15417) Blueprint should have a flag to allow configuring use of RCO vs Retry method
Date Tue, 15 Mar 2016 21:26:33 GMT


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:
>             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

View raw message