The basic method a user of the AS 7 programmatic managment API would use it very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of operation.
Simple Operations
A text representation of simple operation would look like this:
{
"op" => "setCoreThreads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
}
Java code to produce that output would be:
ModelNode op = new ModelNode();
op.get("op").set("setCoreThreads");
ModelNode addr = opB.get("op-addr");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
System.out.println(op);
The order in which the items appear in the request is not relevant. The required elements are:
- op -- String -- The name of the operation being invoked.
- op-addr -- the address of the managed resource against which the request should be executed.
The other key/value pairs are parameter names and their values. The names and values should match what is specified in the operation's description.
Parameters may have any name, except for op, op-addr and rollout-plan.
Composite Operations
The root resource managed by a (Domain|Host|Server)Controller will expose an operation named "composite". This operation executes a list of other operations as a (semi-)atomic unit. The structure of the request for the "composite" operations has the same fundamental structure as a simple operation (operation name, address, params as key value pairs.
{
"op" => "composite",
"op-addr" => [],
"steps" => [
{
"op" => "write-core-threads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
},
{
"op" => "write-core-threads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool2")
],
"count" => 5,
"per-cpu" => 10
}
],
"rollback-on-runtime-failure" => false
}
The "composite" operation takes two parameters:
- steps -- a list, where each item in the list has the same structure as a simple operation request. In the example above each of the two steps is modifying the thread pool configuration for a different pool. There need not be any particular relationship between the steps.
- rollback-on-runtime-failure -- boolean, optional, defaults to true. Whether steps that successfully execute should be reverted if other steps fail at runtime. Note that if any steps modify the persistent configuration, and any of those steps fail, all steps will be reverted. Partial/incomplete changes to the persistent configuration are not allowed. So, this flag only deals with what happens if there is a problem applying an operation to the running state of a server (e.g. actually increasing the size of a runtime thread pool.)
Operations with a Rollout Plan
Operations targetted at domain or host level resources can potentially impact multiple servers. Such operations can include a "rollout plan" detailing the sequence in which the operation should be applied to servers as well as policies for detailing whether the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{
"op" => "setCoreThreads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
"rollout-plan" => "TODO"
}
TODO -- flesh out the structure of the rollout plan. Deployment plans in Alpha1 had a structure that could apply very easily, but it's not particularly intuitive. It was hidden from users by the DeploymentPlanBuilder API. So I want to tweak it a bit to make it more understandable to the end user.
As you can see, the rollout plan is simply another structure at the same level as op, op-addr and the operation parameters.