Mailing-List: contact ambari-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ambari-dev@incubator.apache.org
Date: Thu, 27 Jun 2013 04:36:21 +0000 (UTC)
From: "Eric Yang (JIRA)" <jira@apache.org>
To: ambari-dev@incubator.apache.org
Message-ID: <JIRA.12640689.1365040200906.178469.1372307781531@arcas>
In-Reply-To: <JIRA.12640689.1365040200906@arcas>
References: <JIRA.12640689.1365040200906@arcas>
Subject: [jira] [Commented] (AMBARI-1783) Specification for a cluster
 blueprint consumable by Ambari
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Eric Yang commented on AMBARI-1783:
-----------------------------------

OpenJDK is not a service.  It is a package instead of a service.  Firewall could be an example of isManageable service.  How about simplify the cluster blue print, software stack definition and host manifest?  A cleaner version would be:

Cluster blueprint:

{code}
{ 
  "version": "1.3.0",
  "cluster": {
    "name": "example",
    "services": [
      {
        "name": "filesystem",
        "components": [ "hdfs" ],
      },
      {
        "name": "firewall",
        "components": [ "iptables" ],
        "isManageable": "false"
      }
    ],
    "applications": [
      {
        "name": "my hadoop killer app",
        "components": [ "text-analytics" ],
        "isManageable": "false"
      }
    ],
    "environment": {
      "fs.default.name": "hdfs://localhost:50070/",
      "HADOOP_NAMENODE_OPTS": { "value": "-Xmx5G", "file": "hadoop-env.sh" }
    }
  }
}
{code}

Software stack example:

{code}
{
  "software": {
    "repository": [
      {
        "name": "local",
        "url": "file:///image"
      }
    ],
    "platform": "x86_64",
    "osType": "el6",
    "components": [
      {
        "name":"glusterfs",
        "conflicts": [ "hdfs" ],
        "provides" : "filesystem",
        "packages": [
          {
            "name":"glusterfs",
            "version":"4.3",
            "filename":"gluster-4.3.el6.x86_64.rpm",
            "hostGroup": [ "node" ]
          }
        ]
      },
      {
        "name":"hdfs",
        "conflicts": [ "glusterfs" ],
        "provides" : "filesystem",
        "packages": [
          {
            "name":"java",
            "version":"1.7",
            "filename":"java-1.7.el6.x86_64.rpm"
          },
          {
            "name":"hadoop",
            "version":"1.2.0",
            "filename":"hadoop-1.2.0.el6.x86_64.rpm",
            "dependency":"java"
            "hostGroup": [ "namenode", "secondarynamenode", "datanode" ]
          }
        ]
      },
      {
         "name":"text-analytics",
         "packages": [
           {
             "name":"hadoop",
             "version":"1.2.0",
             "text-analytics-1.2.0.el6.x86_64.rpm"
             "dependency":"filesystem"
           }
         ]
      }
    ]
  }
}
{code}

Host manifest:

{code}
{
  "namenode": [ "nn1" ],
  "secondarynamenode": [ "snn1" ],
  "datanode": [ "dn1", "dn2", "dn3" ]
}
{code}

Notice in cluster blueprint, the new addition section of applications is designed to deploy application in the hadoop environment (HDFS) or virtual environment, there is no local copy stored in local file system.  The running environment is a flatten list of key value pairs, this is designed to make it easier for dev ops to manage the running environment more easily.  The additional overwrite to environment allows to set a specific value for a particular config file.  Host manifest is a flatten list of hostGroups for user friendliness for dev ops.  Conflict, and provide syntax can support swappable component for Hadoop software stack.
                
> 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