ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sumit Mohanty (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-4467) Create new /blueprints REST endpoint
Date Sat, 01 Feb 2014 17:30:09 GMT

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

Sumit Mohanty commented on AMBARI-4467:
---------------------------------------

One of the usage scenario for a blueprint is a way to export and import the definition of
the cluster. For example, Ambari will continue to use its internal structure (that it has
today) to represent the structure. The blueprint will be used only for export/import. My assertion
is that, for any management infrastructure, there will always be a middle layer that translates
the blueprint to internal structure geared towards management. _IOW, the shape is not as critical
as the content._

Host group first works better when the goal is to create an exact copy and one of the step
is to obtain hosts/VMs based on some specification (e.g. slave hosts vs master). It also works
better when you want to add more slave/master hosts. 

Component first works better when one adds/removes/replaces components. Like [~eyang] mentioned,
adding, say Yarn, on an existing blueprint would change the composition of several host groups
and may even require re-creation of host-groups themselves (e.g. not all NodeManager share
DataNode hosts). In fact Ambari's internal structure is an explicit mapping of a component
to a host for flexibility. If you look at the ConfigGroup feature its Service --> Host
group (each service has their own host group).

Based on what I remember from past discussions, depending on what you do with the blueprint
one way of mapping is better than the other - not unlike data structure choices. My understanding
is that creating a copy and adding more slave hosts are the primary use cases - hence the
current choice.

My take is that a blueprint is not optimal for hand editing - either there is a tool or, more
likely, its always exported from a hadoop management infrastructure after the user is happy
with the shape of the deployed cluster. 

> Create new /blueprints REST endpoint
> ------------------------------------
>
>                 Key: AMBARI-4467
>                 URL: https://issues.apache.org/jira/browse/AMBARI-4467
>             Project: Ambari
>          Issue Type: New Feature
>            Reporter: John Speidel
>            Assignee: John Speidel
>              Labels: api-addition, blueprints
>             Fix For: 1.5.0
>
>
> Create a new /blueprints REST endpoint. This endpoint represents an 'abstract blueprint'
or 'template' and doesn't contain cluster specific details such specific host information.
> This initial jira will be limited to basic blueprint information and will not contain
configuration elements.  These additional elements will be added in subsequent patches.
> Available operations are get, create and delete.  Update is not supported because blueprints
are immutable.
> Example of a simple blueprint resource:
> {code}
> {
>   "href" : "http://172.18.193.10:8080/api/v1/blueprints/bp1",
>   "host_groups" : [
>     {
>       "name" : "foo",
>       "components" : [
>         {
>           "name" : "component2"
>         },
>         {
>           "name" : "component1"
>         },
>         {
>           "name" : "component4"
>         },
>         {
>           "name" : "component3"
>         }
>       ],
>       "cardinality" : "2"
>     },
>     {
>       "name" : "bar",
>       "components" : [
>         {
>           "name" : "component5"
>         }
>       ],
>       "cardinality" : "1"
>     }
>   ],
>   "Blueprints" : {
>     "blueprint_name" : "bp1",
>     "stack_name" : "HDP",
>     "stack_version" : "1.3.3"
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message