SpecificationMargo Management Interface

Deployment Status

While applying a new desired state, the device's management client MUST provide the Workload Fleet Manager service with an indication of the current workload deployment status. This is done by calling the Device API's deployment status endpoint.

Note: This assumes consistent connection to the WFM, we will address intermittent or extended disconnection scenarios in the future.

Route and HTTP Methods

POST /api/v1/deployments/{deploymentId}/status

Route Parameters

ParameterTypeRequired?Description
{deploymentId}stringYThe UUID of the ApplicationDeployment YAML being reported.

Response Codes

CodeDescription
200 OKThe deployment status was updated successfully.
201 CreatedThe deployment status was created successfully.
400 Bad RequestMalformed request body.
403 ForbiddenThe request is not authorized by the WFM's local policy (for example, the client relationship has been retired; see Authorization).
422 Unprocessable ContentRequest body includes a semantic error.

Request Body Attributes

FieldsTypeRequired?Description
deploymentIdstringYThe unique identifier UUID of the deployment specification. Needs to be assigned by the Workload Fleet Management Software.
deviceIdstringN*Id of the device hosting the deployment. Includes the full device hierarchy if applicable. * This attribute is required when reporting on behalf of a child-device.
adoptedManifestVersionnumberYThe manifestVersion of the most recent state manifest the WFM client has adopted for this deployment. See the Adopted Manifest Version section below.
status[]statusYElement that defines overall deployment status. See the Status Attributes section below.
components[]componentsYElement that defines the individual component's deployment status. See the Component Attributes section below.

Status Attributes

FieldsTypeRequired?Description
statestringYCurrent state of the overall deployment. The state value MUST be one the following options: pending, installing, installed, removing, removed, failed. The overall deployment status MUST reflect the most severe of the components states, following this precedence: failed > removing > installing > pending > removing > installed.
errorErrorNElement that defines the overall installation error if one occurred. See the Error Attributes section below.

Component Attributes

AttributeTypeRequired?Description
namestringYName of the deployment component, inherited via the deployment specification
statestringYThe component's current deployment state of the component. MUST be one of the following options: pending, installing, installed, removing, removed, failed
errorErrorNElement that defines the components installation error if one occurred. See the Error Attributes section below.

Note: The components array MUST contain one entry for each "component" defined in the referenced ApplicationDeployment manifest.

Error Attributes

FieldsTypeRequired?Description
codestringYAssociated error code following a component failure during installation.
sourcestringYIdentifies the source of the error. It is set to the device id, with its full hierarchy if applicable, of the device generating the error, or to the component name of the component generating the error.
messagestringYAssociated error message that provides further details to the WFM about the error that was encountered.

When the error is generated by a see-thru gateway, the source attribute of the error structure MUST be set to the gateway device id, with its full hierarchy if applicable.

When the error is not generated by a see-thru gateway, the source of the status.error attribute MUST be set to the name of the deployment as defined in the metadata.name attribute of the application deployment manifest.

When the error is not generated by a see-thru gateway, the source of the components.error attribute MUST be set to the name of the component as defined in the components[].name for that component.

Note: Most error codes and messages are implementation-specific. The purpose of the source attribute is to avoid collision between reserved error codes and implementation-specific error codes.

Reserved codes for gateway-generated errors:
Error CodeMessageSourceDescription
101Unknown child device IDId of the gatewayThe gateway cannot identify the child device with the given ID.
102Child device unreachableId of the gatewayThe gateway cannot establish a connection with the child device.
103Autonomous placement not supportedId of the gatewayThe gateway is not capable of autonomously selecting the child-device for the deployment.

When the error used is a reserved code for a gateway-generated error, the source attribute MUST be set to the id of the gateway, with its full hierarchy if applicable.

Adopted Manifest Version

A state manifest defines a revision of each deployment it carries. A WFM client has adopted that revision when it holds it and has begun applying it. Adoption is independent of the outcome. The status.state attribute carries the outcome.

The WFM client MUST populate the adoptedManifestVersion attribute with the manifestVersion of the most recent state manifest it has adopted for the reported deployment. A reported version N means the client has taken up the deployment as manifest N defined it. The reported version MUST match the revision of the deployment the client holds. A client still on an older revision reports that older version.

Fetching a newer state manifest does not by itself advance the reported version for a deployment. Until the client begins applying the deployment's newer revision, it keeps reporting the version of the revision it still holds. The reported version need not be the version at which the deployment last changed. A client that has lost its local state and resynchronized reports the version it resynchronized against, which can be later.

The attribute is present in every status report. A client learns of a deployment from a versioned state manifest, so it always has a version to report for a deployment it has taken up. On a first install the client reports the version of the manifest it adopted the deployment from, even if applying it fails. There is no reserved value for "no previous version".

Note: Manifest versions increase monotonically and never repeat, so the WFM can order any reported version against the versions it has published, even when a deployment's content reverts to an earlier revision.

Example Deployment Status Manifest Request

{
    "deploymentId": "a3e2f5dc-912e-494f-8395-52cf3769bc06",
    "deviceId": "plant-alfa-zone1-edge01",
    "adoptedManifestVersion": 7,
    "status": {
        "state": "pending",
        "error": {
            "code": "",
            "source": "",
            "message": ""
        }
    },
    "components": [
        {
            "name": "digitron-orchestrator",
            "state": "pending",
            "error": {
                "code":"",
                "source": "",
                "message":""
            }
        },
        {
            "name": "database-services",
            "state": "pending",
            "error": {
                "code": "",
                "source": "",
                "message": ""
            }
        }
    ]
}