[
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}
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.
This Jira will be updated shortly with more information on this extensive set
of enhancements and changes.
> 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}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
