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