You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Brian Swan (JIRA)" <ji...@apache.org> on 2013/07/01 01:04:20 UTC

[jira] [Commented] (AMBARI-1783) Specification for a cluster blueprint consumable by Ambari

    [ 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