ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Speidel (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-10750) Initial Implementation of Advanced API Cluster Provisioning Functionality
Date Mon, 27 Apr 2015 14:59:38 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

John Speidel updated AMBARI-10750:
----------------------------------
    Description: 
API based (blueprint) cluster provisioning modifications and enhancements which will provide
for more flexible, scalable and robust cluster provisioning.

This will include API and backend changes.

- Allow a host count to be specified in the cluster creation template instead of host names.
 This is documented in https://issues.apache.org/jira/browse/AMBARI-6275
- Allow cluster creation or scaling to be started via the REST API prior to all/any hosts
being available.  As hosts register with Ambari server they will be matched to request host
groups and provisioned according to the requested topology
- Allow host predicates to be specified along with host count to provide more flexibility
in matching hosts to host groups.  This will allow for host flavors where different host groups
are matched to different host flavors
- Break up the current monolithic provisioning request into a request for each host operation.
 For example, install on host A, start on host A, install on hostB, etc.  This will allow
hosts to make progress even when another host encounters a failure.

Changes to the API:
Addition of "host_count" and "host_predicate" to both the cluster creation template and add
host api. Previously a host name had to be specified for these api call but now a host count
can be specified instead.  When specifying a host count, a predicate can also be specified
which gives fine grain control over which hosts are matched to which host groups.

Cluster Create Template:
{code}
{
  "blueprint" : "bp1",
  "host_groups" :[
    { 
      "name" : "master",  
      "hosts" : [          
        { 
          "fqdn" : "john2.novalocal"
        }
      ]
    },  
    { 
      "name" : "slave",      
      "hosts" : [          
        { 
          "host_count" : "5",
          "host_predicate" : "Hosts/cpu_count>1"           
        }
      ]
    }
  ]
}
{code}

Add Host API:
{code}
[
  {
      "blueprint" : "bp1",
      "host_group" : "slave",
      "host_count" : 5
  },
  {
      "blueprint" : "bp1",
      "host_group" : "super-slave",
      "host_count" : 5,
      "host_predicate" : "Hosts/cpu_count>2&Hosts/total_mem>3000000"
  }
]
{code}

The syntax of the host predicate is standard API query syntax which is described here:
https://github.com/apache/ambari/blob/trunk/ambari-server/docs/api/v1/index.md#query-parameters

Currently, the properties which are available to query are exactly the same as those available
for the /api/v1/hosts endpoint.

  was:
API based (blueprint) cluster provisioning modifications and enhancements which will provide
for more flexible, scalable and robust cluster provisioning.

This will include API and backend changes.

- Allow a host count to be specified in the cluster creation template instead of host names.
 This is documented in https://issues.apache.org/jira/browse/AMBARI-6275
- Allow cluster creation or scaling to be started via the REST API prior to all/any hosts
being available.  As hosts register with Ambari server they will be matched to request host
groups and provisioned according to the requested topology
- Allow host predicates to be specified along with host count to provide more flexibility
in matching hosts to host groups.  This will allow for host flavors where different host groups
are matched to different host flavors
- Break up the current monolithic provisioning request into a request for each host operation.
 For example, install on host A, start on host A, install on hostB, etc.  This will allow
hosts to make progress even when another host encounters a failure.

Changes to the API:
Addition of "host_count" and "host_predicate" to both the cluster creation template and add
host api. Previously a host name had to be specified for these api call but now a host count
can be specified instead.  When specifying a host count, a predicate can also be specified
which gives fine grain control over which hosts are matched to which host groups.

Cluster Create Template:
{code}
{
  "blueprint" : "bp1",
  "host_groups" :[
    { 
      "name" : "master",  
      "hosts" : [          
        { 
          "fqdn" : "john2.novalocal"
        }
      ]
    },  
    { 
      "name" : "slave",      
      "hosts" : [          
        { 
          "host_count" : "5",
          "host_predicate" : "Hosts/cpu_count>1"           
        }
      ]
    }
  ]
}
{code}

Add Host API:
{code}
[
  {
      "blueprint" : "bp1",
      "host_group" : "slave",
      "host_count" : 5
  },
  {
      "blueprint" : "bp1",
      "host_group" : "super-slave",
      "host_count" : 5,
      "host_predicate" : "Hosts/cpu_count>2&Hosts/total_mem>3000000"
  }
]
{code}


> Initial Implementation of Advanced API Cluster Provisioning Functionality
> -------------------------------------------------------------------------
>
>                 Key: AMBARI-10750
>                 URL: https://issues.apache.org/jira/browse/AMBARI-10750
>             Project: Ambari
>          Issue Type: Task
>          Components: ambari-server, blueprints
>    Affects Versions: Ambari-2.1
>            Reporter: John Speidel
>            Assignee: John Speidel
>             Fix For: Ambari-2.1
>
>         Attachments: AMBARI-10750.patch
>
>
> API based (blueprint) cluster provisioning modifications and enhancements which will
provide for more flexible, scalable and robust cluster provisioning.
> This will include API and backend changes.
> - Allow a host count to be specified in the cluster creation template instead of host
names.  This is documented in https://issues.apache.org/jira/browse/AMBARI-6275
> - Allow cluster creation or scaling to be started via the REST API prior to all/any hosts
being available.  As hosts register with Ambari server they will be matched to request host
groups and provisioned according to the requested topology
> - Allow host predicates to be specified along with host count to provide more flexibility
in matching hosts to host groups.  This will allow for host flavors where different host groups
are matched to different host flavors
> - Break up the current monolithic provisioning request into a request for each host operation.
 For example, install on host A, start on host A, install on hostB, etc.  This will allow
hosts to make progress even when another host encounters a failure.
> Changes to the API:
> Addition of "host_count" and "host_predicate" to both the cluster creation template and
add host api. Previously a host name had to be specified for these api call but now a host
count can be specified instead.  When specifying a host count, a predicate can also be specified
which gives fine grain control over which hosts are matched to which host groups.
> Cluster Create Template:
> {code}
> {
>   "blueprint" : "bp1",
>   "host_groups" :[
>     { 
>       "name" : "master",  
>       "hosts" : [          
>         { 
>           "fqdn" : "john2.novalocal"
>         }
>       ]
>     },  
>     { 
>       "name" : "slave",      
>       "hosts" : [          
>         { 
>           "host_count" : "5",
>           "host_predicate" : "Hosts/cpu_count>1"           
>         }
>       ]
>     }
>   ]
> }
> {code}
> Add Host API:
> {code}
> [
>   {
>       "blueprint" : "bp1",
>       "host_group" : "slave",
>       "host_count" : 5
>   },
>   {
>       "blueprint" : "bp1",
>       "host_group" : "super-slave",
>       "host_count" : 5,
>       "host_predicate" : "Hosts/cpu_count>2&Hosts/total_mem>3000000"
>   }
> ]
> {code}
> The syntax of the host predicate is standard API query syntax which is described here:
> https://github.com/apache/ambari/blob/trunk/ambari-server/docs/api/v1/index.md#query-parameters
> Currently, the properties which are available to query are exactly the same as those
available for the /api/v1/hosts endpoint.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message