[
https://issues.apache.org/jira/browse/AMBARI-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696433#comment-13696433
]
Eric Yang commented on AMBARI-1783:
-----------------------------------
The original design to classify software as a service, it is somewhat
simplified the fact that a service is composed of multiple software components.
At the same time, the service internal can be replaced by alternative
implementation. Such as, file system can be represented by ext3, xfs or ntfs.
It is somewhat harder to define substitution services later, if xfs is being
promoted as a service rather than file system as a service. However, it is
best to describe this part as clear as possible for developer to implement the
interface properly.
For the running environment, it is good to collapse the name space because
references can be reused across components. For example, JAVA_HOME reference
can be used in hadoop-env.sh, and hbase-env.sh, and several dependent
components. Today, hadoop-env.sh has one value for JAVA_HOME, and hbase-env.sh
has another value for JAVA_HOME. Both values are not linked together with the
JAVA_HOME reference. Operator needs to remember to change each occurrence of
JAVA_HOME through all configurations sections. For improve operator
experience, collapsing the namespace can avoid searching through files and
namespace resolution between services/components.
The optimization are meant to improve the management ability for both devs and
ops.
> Specification for a cluster blueprint consumable by Ambari
> ----------------------------------------------------------
>
> Key: AMBARI-1783
> URL: https://issues.apache.org/jira/browse/AMBARI-1783
> Project: Ambari
> Issue Type: New Feature
> Affects Versions: 1.3.1
> Reporter: Sumit Mohanty
> Assignee: Sumit Mohanty
> Fix For: 1.3.1
>
> Attachments: Ambari-BluePrint-0.3.docx, Ambari-BluePrint-0.4.docx,
> HostComponentMapping.txt, HostManifest.txt, PackageConfiguration.txt,
> PackageDefinition.txt, Sample_Deployment1_HDPStack_1_3_0_Configuration.txt,
> Sample_Deployment1_HostComponentMapping.txt,
> Sample_Deployment1_HostManifest.txt, Sample_HDPStack_1_3_0_Definition.txt,
> Schema_HostComponentMapping.txt, Schema_HostManifest.txt,
> Schema_PackageConfiguration.txt, Schema_PackageDefinition.txt
>
>
> Deployment of a hadoop cluster can be modeled as the mapping of a stack
> definition to a set of host while satisfying placement constraints. A stack
> definition refers to the description of various services that comprise a
> hadoop stack (e.g. HDP-1.2.1), components associated with the services, and
> configuration properties. A set of available hosts is specified through a
> host-manifest that lists the available hosts and relevant
> properties/characteristics of each host. A cluster blueprint is specification
> of a hadoop stack mapped to a set of hosts. Mapping to a host can be a direct
> mapping - e.g. deploy this component X on host Y or a host can be specified
> as a set of requirements which is used to select the most appropriate host(s)
> from a host-manifest.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
