ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Speidel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-6275) Add support for "add hosts" with Blueprints API
Date Thu, 23 Oct 2014 20:46:34 GMT

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

John Speidel commented on AMBARI-6275:
--------------------------------------

[~nalex]

Regarding your comment on the api only doing "one" thing, this is a "high" level api that
does many things under the covers.  In this way, it is similar to the blueprint api for provisioning
a cluster.  That api does many things such as creating all necessary cluster resources, updating
and setting configurations, installing all components and starting all services/components.
 All of these things can be done via lower level api calls but it is complex and hard to get
right.  That is why we are creating higher level api's such as the blueprint api.  This proposed
api will also do many things under the covers such as creating the necessary resource objects,
updating configurations, installing and starting services/components, etc.  All of these things
can already be done via the existing api, but again, it is difficult.  So, in my opinion,
it makes sense to do some associated operations automatically but that we need to not overreach.
 We need to only do things automatically where the user wouldn't ever want to do manually.
 For tasks where a user may want to have control such as service restart, data redistribution,
etc, the goal would be to allow the user the flexibility to execute these tasks when they
want to but to make this as easy  and intuitive as possible.  This would include both identifying
potentially necessary tasks and their associated api invocations as well as possibly having
the steps done automatically.  This is difficult and will take time and debate and that is
why it isn't included in this 2.0 task. 

Answers to your questions:
1) If a host is specified to "clone" that contains master services, the user would get a 400
response (Bad Request) that indicated that adding of master nodes is not currently allowed.
2) Yes, this will not affect the requirement that agents be pre-installed on each host and
that each agent has registered with the server.  
3) I assume that you are asking about Kerberos.  Kerberos work is being tracked in the epic
: AMBARI-7204 .  So the short answer is that this add hosts api will be kerberos aware as
a result of integration with the Kerberos work currently being done.  This means that if you
add hosts to a kerberos enabled cluster that the new nodes will also be kerberos enabled after
the add host call completes.

Regarding remove hosts: AMBARI-7940.  As with add hosts, it is currently possible to remove
hosts via lower level api calls but would be simplified via a new higher level api.  This
Jira is pretty sparse at the moment but will be updated in the near future and announced via
a [DISCUSS] thread via dev@ambari.

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

Mime
View raw message