ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-1783) Specification for a cluster blueprint consumable by Ambari
Date Mon, 01 Jul 2013 00:04:20 GMT

    [ 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

Mime
View raw message