[
https://issues.apache.org/jira/browse/AMBARI-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178949#comment-14178949
]
John Speidel commented on AMBARI-6275:
--------------------------------------
[~u39kun] For the "add hosts" work in 2.0, I am not proposing any additional
retry functionality or idempotency guarantees.
I understand how important the ability to retry deployments is, but the problem
is bigger in scope than "add hosts" so it will be addressed as a distinct
project.
Failure tolerance and retry behavior are really important to any long running
asynchronous request so any solution would likely augment the current lower
level request model.
> Add support for "add hosts" with Blueprints API
> -----------------------------------------------
>
> Key: AMBARI-6275
> URL: https://issues.apache.org/jira/browse/AMBARI-6275
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
> Affects Versions: 1.7.0
> Reporter: Yusaku Sako
> Assignee: John Speidel
> Fix For: 2.0.0
>
>
> Support for "adding hosts" based on *blueprint* style *host_group* via Ambari
> REST API. There are two scenarios to consider for this JIRA:
> 1) Add hosts based on an existing host in the cluster (and it's *blueprint*
> style *host_group* component layout). This enables the user to add hosts with
> components similar to existing hosts in the cluster. For example: expand this
> cluster with these X hosts and make each of these hosts like Y host
> (components + configs) existing in the cluster.
> 2) Add hosts based on components + configs. This would be a verbose method
> that uses *blueprint* style *host_groups* and *configs* to allow you to add
> hosts to a cluster that do not necessarily have a component layout or config
> of a similar host existing in the cluster. For example: expand this cluster
> with these X hosts and make each of these hosts include Y components with Z
> configs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
