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