ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Swan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-1783) Specification for a cluster blueprint consumable by Ambari
Date Sun, 30 Jun 2013 23:04:20 GMT

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

Brian Swan commented on AMBARI-1783:
------------------------------------

Eric: In some cases, it makes sense to think of OpenJDK (or Python, or ...) as a service (e.g.
deploying Hadoop in a virtual environment or in a cloud environment). In these scenarios,
when a "service" is not manageable, it is just software to be installed. 

By suggesting that the "running environment" should just be a flattened list of key-value
pairs, are you saying that this would be preferable to grouping them under core-site, hdfs-site,
etc. ? The current design is such that it prevents a deployment tool (such as Ambari, but
others too) from needing to maintain any sort of configuration mapping. (In general, I think
it's important to consider that these manifest files may be consumed by deployment tools other
than Ambari.)

I like your suggestions for being able to add a configuration file or reference one in place
of the key-value pairs (if I've interpreted your suggestion correctly). I also like the suggestion
for a "conflict" property.
                
> 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