|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Class Summary | |
---|---|
Cluster | This class represents a real cluster of Cluster.Instance s. |
Cluster.Instance | This class represents a real node running in a cluster. |
ClusterAction | Performs an action on a cluster. |
ClusterActionEvent | An event object which is fired when a ClusterAction occurs. |
ClusterActionHandler | A callback interface for cluster actions that apply to instances in a given role. |
ClusterActionHandlerSupport | This is a utility class to make it easier to implement
ClusterActionHandler . |
ClusterSpec | This class represents the specification of a cluster. |
ClusterSpec.InstanceTemplate | This class describes the type of instances that should be in the cluster. |
ComputeServiceContextBuilder | A convenience class for building jclouds ComputeServiceContext objects. |
RolePredicates | Predicate s for matching Cluster.Instance s with certain cluster roles. |
Service | This class represents a service that a client wants to use. |
ServiceFactory | This class is used to create Service instances. |
Enum Summary | |
---|---|
ClusterSpec.Property |
The Whirr Service API.
A service is an instance of a coherent system running on one or more machines.
A role is a part of a service running on a single machine. A role typically corresponds to a single process or daemon, although this is not required.
An instance template (ClusterSpec.InstanceTemplate
) is a specification of the role sets and
cardinalities that make up a cluster. For example,
1 role-a+role-b,4 role-c
specifies a cluster in which one node is in roles role-a and
role-b, and four nodes are in role role-c.
A cluster action (ClusterAction
) is an action that is performed on a set of machines
in a cluster. Examples of cluster actions include 'bootstrap' and 'configure'.
You can launch or destroy clusters using an instance of
Service
.
Whirr launches a cluster
by running the bootstrap action, followed by the
configure action. For each of these actions Whirr follows these rules:
The first rule implies that you can't rely on one template being processed first. In fact, Whirr will process them all in parallel. So to transfer information from one role to another (in a different template) you should use different actions. For example, use the configure phase to get information about another role that was set in its bootstrap phase.
The second rule implies that a cluster action handler for a given role will be run more than once if it appears in more than one template.
A cluster is destroyed
by running the destroy action.
For each role in a service you must write a
ClusterActionHandler
, which allows you to
run code at various points in the lifecycle. For example, you can specify a
script that must be run on bootstrap, and another at configuration time.
Roles for a service are discovered using Java's service-provider loading
facility defined by ServiceLoader
. It's very easy to
register your service. Simply create a file with the following path (assuming
a Maven directory structure):
src/main/resources/META-INF/services/org.apache.whirr.service.ClusterActionHandler
Then for each ClusterActionHandler
implementation add its fully qualified name as a line in the file:
org.example.MyClusterActionHandlerForRoleA org.example.MyClusterActionHandlerForRoleB
If you service is not a part of Whirr, then you can install it by first installing Whirr, then dropping the JAR file for your service into Whirr's lib directory.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |