Format of a Detyped Operation Response

The basic method a user of the AS 7 programmatic managment API would use is 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 the return value.

 

For the format of the request, see this page.

 

See this page for a more in depth example of using the native management API.

 

Simple Responses


Simple responses are provided by the following types of operations:

 

  • Non-composite operations that target a single server. (See below for more on composite operations).
  • Non-composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a simple read of a domain configuration property.)

 

The response will always include a simple boolean outcome field, with one of three possible values:

 

  • success -- the operation executed successfully
  • failed -- the operation failed
  • cancelled -- the execution of the operation was cancelled. (This would be an unusual outcome for a simple operation which would generally very rapidly reach a point in its execution where it couldn't be cancelled.)

 

The other fields in the response will depend on whether the operation was sucessful.

 

The response for a failed operation:

 

{
    "outcome" => "failed",
    "failure-description" => "[DOM-1234] Some failure message"
}

 

A response for a successful operation will include an additional field:

 

  • result -- the return value, or undefined for void operations or those that return null

 

A non-void result:

 

{
    "outcome" => "success",
    "result" => {
        "name" => "Brian",
        "age" => 22
    }
}

 

A void result with a compensating operation:

 

{
    "outcome" => "success",
    "result" => undefined
}

 

The response for a cancelled operation has no other fields:

 

{
    "outcome" => "cancelled"
}

Response Headers

 

Besides the standard outcome, result and failure-description fields described above, the response may also include various headers that provide more information about the affect of the operation or about the overall state of the server. The headers will be child element under a field named response-headers. For example:

 

{
    "outcome" => "success",
    "result" => undefined,
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }

}

 

A response header is typically related to whether an operation could be applied to the targetted runtime without requiring a restart of some or all services, or even of the target process itself. Please see "Applying Updates to Runtime Services" on the Detyped Description of the AS 7 Management Model wiki for a discussion of the basic concepts related to what happens if an operation requires a service restart to be applied.

 

The current possible response headers are:

 

  • operation-requires-reload -- boolean -- indicates that the specific operation that has generated this response requires a restart of all services in the process in order to take effect in the runtime. This would typically only have a value of 'true'; the absence of the header is the same as a value of 'false.'
  • operation-requires-restart -- boolean -- indicates that the specific operation that has generated this response requires a full process restart in order to take effect in the runtime. This would typically only have a value of 'true'; the absence of the header is the same as a value of 'false.'
  • process-state -- enumeration -- Provides information about the overall state of the target process. One of the following values:
    • starting -- the process is starting
    • running -- the process is in a normal running state. The process-state header would typically not be seen with this value; the absence of the header is the same as a value of 'running'.
    • reload-required -- some operation (not necessarily this one) has executed that requires a restart of all services in order for a configuration change to take effect in the runtime.
    • restart-required -- some operation (not necessarily this one) has executed that requires a full process restart  in order for a configuration change to take effect in the runtime.
    • stopping -- the process is stopping

 

Basic Composite Operation Responses

 

A composite operation is one that incorporates more than one simple operation in a list and executes them atomically. See the "Composite Operations" section here for more information.

 

Basic composite responses are provided by the following types of operations:

 

  • Composite operations that target a single server.
  • Composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a list of simple reads of domain configuration properties.)

 

The high level format of a basic composite operation response is largely the same as that of a simple operation response, although there is an important semantic difference. For a composite operation, the meaning of the outcome flag is controlled by the value of the operation request's rollback-on-runtime-failure header field. If that field was false (default is true), the outcome flag will be success if any of the composite operation's steps was successful.

 

What's distinctive about a composite operation response is the result field. First, even if the operation was not successful, the result field will usually be present. (It won't be present if there was some sort of immediate failure that prevented the responder from even attempting to execute the individual operations.)  Second, the content of the result field will be a list. Each element in the list will record the result of the corresponding element in the steps field of the composite operation request. So each individual operation in the composite operation will have its result recorded.

 

The individual operation results will have the same basic format as the simple operation results described above. However, there are some differences from the simple operation case when the individual operation's outcome flag is failed.  These relate to the fact in a composite operation, individual operations can be rolled back or not even attempted.

 

If an individual operation was not even attempted (because the overall operation was cancelled or, more likely, a prior operation failed):

 

{
    "outcome" => "cancelled"
}

 

An individual operation that failed and was rolled back:

 

{
    "outcome" => "failed",
    "failure-description" => "[DOM-1234] Some failure message",
    "rolled-back" => true
}

 

An individual operation that itself succeeded but was rolled back due to failure of another operation:

 

{
    "outcome" => "failed",
    "result" => {
        "name" => "Brian",
        "age" => 22
    },
    "rolled-back" => true
}

 

An operation where the attempt at rollback was unsuccessful:

 

{
    "outcome" => "failed",
    "failure-description" => "[DOM-1234] Some failure message",
    "rolled-back" => false,
    "rollback-failure-description" => "[DOM-9876] Some other failure message"
}

 

 

Here's an example of the response for a successful 2 step composite operation:

 

{
    "outcome" => "success",
    "result" => [
        {
            "outcome" => "success",
            "result" => {
                "name" => "Brian",
                "age" => 22
            }
        },
        {
            "outcome" => "success",
            "result" => undefined
        }
    ]
}

 

And for a failed 3 step composite operation, where the first step succeeded and the second failed, triggering cancellation of the 3rd and rollback of the others:

 

{
    "outcome" => "failed",
    "failure-description" => "[DOM-9999] Composite operation failed; see individual operation results for details",
    "result" => [
        {
            "outcome" => "failed",
            "result" => {
                "name" => "Brian",
                "age" => 22
            },
            "rolled-back" => true
        },
        {
            "outcome" => "failed",
            "failure-description" => "[DOM-1234] Some failure message",
            "rolled-back" => true
        },
        {
            "outcome" => "cancelled"
        }
    ]
}

 


Multi-Server Responses

 

Multi-server responses are provided by operations that target a DomainController or HostController and require the responder to apply the operation on multiple servers and aggregate their results (e.g. nearly all domain or host configuration updates.)

 

Multi-server operations are executed in several stages.

 

First, the operation may need to be applied against the authoritative configuration model maintained by the DomainController (for domain.xml confgurations) or a HostController (for a host.xml configuration). If there is a failure at this stage, the operation is automatically rolled back, with a response like this:

 

{
    "outcome" => "failed",
    "domain-failure-description" => "[DOM-3333] Failed to apply X to the domain model"
}

if the operation was addressed to the domain model, or like this:

 

{
    "outcome" => "failed",
    "host-failure-description" => "[DOM-3334] Failed to apply Y to the host model"
}

 

if the operation was addressed to a host model.

 

If the operation was addressed to the domain model, in the next stage the DomainController will ask each HostController to apply it to its local copy of the domain model. If any HostController fails to do so, the DomainController will tell all HostControllers to revert the change, and it will revert the change locally as well. The response to the client will look like this:

 

{
    "outcome" => "failed",
    "host-failure-descriptions" => {
        "hostA" => "[DOM-3333] Failed to apply to the domain model",
        "hostB" => "[DOM-3333] Failed to apply to the domain model"
    }
}

 

If the preceding stages succeed, the operation will be pushed to all affected servers. If the operation is successful on all servers, the response will look like this (this operation has a void response, hence the result for each server is undefined):

 

{
    "outcome" => "success",
    "server-groups" => {
        "groupA" => {
            "serverA-1" => {
                "host" => "host1",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            },
            "serverA-2" => {
                "host" => "host2",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            }
        },
        "groupB" => {
            "serverB-1" => {
                "host" => "host1",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            },
            "serverB-2" => {
                "host" => "host2",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            }
        }
    }
}

 

The operation need not succeed on all servers in order to get an "outcome" => "success" result. All that is required is that it succeed on at least one server without the rollback policies in the rollout plan triggering a rollback on that server. (TODO: consider something like "outcome" => "partial" for this case, and for partially successful composite operations.) An example response in such a situation would look like this:

 

{
    "outcome" => "success",
    "server-groups" => {
        "groupA" => {
            "serverA-1" => {
                "host" => "host1",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            },
            "serverA-2" => {
                "host" => "host2",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            }
        },
        "groupB" => {
            "serverB-1" => {
                "host" => "host1",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined,
                    "rolled-back" => true
                }
            },
            "serverB-2" => {
                "host" => "host2",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined,
                    "rolled-back" => true
                }
            },
            "serverB-3" => {
                "host" => "host3",
                "response" => {
                    "outcome" => "failed",
                    "failure-description" => "[DOM-4556] Something didn't work right",
                    "rolled-back" => true
                }
            }
        }
    }
}

 

Finally, if the operation fails or is rolled back on all servers, an example response would look like this:

 

{
    "outcome" => "failed",
    "server-groups" => {
        "groupA" => {
            "serverA-1" => {
                "host" => "host1",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            },
            "serverA-2" => {
                "host" => "host2",
                "response" => {
                    "outcome" => "success",
                    "result" => undefined
                }
            }
        },
        "groupB" => {
            "serverB-1" => {
                "host" => "host1",
                "response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "rolled-back" => true
                }
            },
            "serverB-2" => {
                "host" => "host2",
                "response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "rolled-back" => true
                }
            },
            "serverB-3" => {
                "host" => "host3",
                "response" => {
                    "outcome" => "failed",
                    "failure-description" => "[DOM-4556] Something didn't work right",
                    "rolled-back" => true
                }
            }
        }
    }
}

 

TODO: discuss some nuances related to multi-server composite operations, particularly the fact that different items in the composite may execute on different sets of servers, or only on the DC or the HC.