EVerest API definition for lifecycle control 1.0.0

API for EVerest modules and clients to control the modules lifecycle. Provides facilities to (re)start and stop modules and monitor their status. Experimental. This API is exempt from the EVerest stability guarantees and the deprecation period; channels, operations and message payloads may change without further notice until it is promoted to stable.

  • #EVerest
  • #Lifecycle

Servers

  • mqtt://localhost:1883/everest_api/1/lifecycle/mqttdefault

    default local MQTT

Operations

  • REQUEST m2e/stop_modules

    Request EVerest to stop all currently running modules.

    Operation IDsend_request_stop_modules

    Available only on servers:

    Accepts the following message:

    Stop modules requestsend_request_stop_modules

    Request EVerest to stop all currently running modules.

    Message IDsend_request_stop_modules
    object

    Examples

    REPLY INFORMATION

    REPLY CHANNEL INFORMATION

    Reply will be directed to the address specified at this location: $message.header#/replyTo

    REPLY address information

    REPLY will be sent to the address provided in:$message.header#/replyTo
  • RECEIVE

    Operation IDreceive_reply_stop_modules

    Available only on servers:

    Accepts the following message:

    Stop modules replyreceive_reply_stop_modules

    Reply indicating the result of stopping modules.

    Message IDreceive_reply_stop_modules
    object

    Result when requesting to stop the modules

    Examples

  • REQUEST m2e/get_everest_version

    Request EVerest to send its version.

    Operation IDsend_request_get_everest_version

    Available only on servers:

    Accepts the following message:

    Get EVerest version requestsend_request_get_everest_version

    Request EVerest to send its version.

    Message IDsend_request_get_everest_version
    object

    Examples

    REPLY INFORMATION

    REPLY CHANNEL INFORMATION

    Reply will be directed to the address specified at this location: $message.header#/replyTo

    REPLY address information

    REPLY will be sent to the address provided in:$message.header#/replyTo
  • RECEIVE

    Operation IDreceive_reply_get_everest_version

    Available only on servers:

    Accepts the following message:

    EVerest version replyreceive_reply_get_everest_version

    Reply to get EVerest version request.

    Message IDreceive_reply_get_everest_version
    object

    Version designators of the running EVerest instance

    Examples

  • REQUEST m2e/start_modules

    Request EVerest to start modules.

    Operation IDsend_request_start_modules

    Available only on servers:

    Accepts the following message:

    Start modules requestsend_request_start_modules

    Request EVerest to start modules.

    Message IDsend_request_start_modules
    object

    Examples

    REPLY INFORMATION

    REPLY CHANNEL INFORMATION

    Reply will be directed to the address specified at this location: $message.header#/replyTo

    REPLY address information

    REPLY will be sent to the address provided in:$message.header#/replyTo
  • RECEIVE

    Operation IDreceive_reply_start_modules

    Available only on servers:

    Accepts the following message:

    Start modules replyreceive_reply_start_modules

    Reply indicating the result of starting modules.

    Message IDreceive_reply_start_modules
    object

    Result when requesting to start the modules

    Examples

  • RECEIVE e2m/status

    Published when EVerest execution status changes.

    Operation IDreceive_status

    Available only on servers:

    Accepts the following message:

    Execution status updatereceive_status

    Published when EVerest execution status changes.

    Message IDreceive_status
    object

    Execution status summary. Will include all the optional fields, if everest_running is true. A false everest_running carries no other field: the manager publishes exactly this payload when it shuts down, and registers it as its MQTT last will for the case where it dies before getting that far.

    Examples

Messages

  • #1Stop modules requestsend_request_stop_modules

    Request EVerest to stop all currently running modules.

    Message IDsend_request_stop_modules
    object
  • #2Stop modules replyreceive_reply_stop_modules

    Reply indicating the result of stopping modules.

    Message IDreceive_reply_stop_modules
    object

    Result when requesting to stop the modules

  • #3Get EVerest version requestsend_request_get_everest_version

    Request EVerest to send its version.

    Message IDsend_request_get_everest_version
    object
  • #4EVerest version replyreceive_reply_get_everest_version

    Reply to get EVerest version request.

    Message IDreceive_reply_get_everest_version
    object

    Version designators of the running EVerest instance

  • #5Start modules requestsend_request_start_modules

    Request EVerest to start modules.

    Message IDsend_request_start_modules
    object
  • #6Start modules replyreceive_reply_start_modules

    Reply indicating the result of starting modules.

    Message IDreceive_reply_start_modules
    object

    Result when requesting to start the modules

  • #7Execution status updatereceive_status

    Published when EVerest execution status changes.

    Message IDreceive_status
    object

    Execution status summary. Will include all the optional fields, if everest_running is true. A false everest_running carries no other field: the manager publishes exactly this payload when it shuts down, and registers it as its MQTT last will for the case where it dies before getting that far.

Schemas

  • StopModulesResultEnum
    string

    Possible results for stop module requests

    • Stopping: Accepted and modules are commanded to stop but haven't done so yet
    • NoModulesToStop: Accepted, but a no-op since there were no modules running
    • Rejected: Rejected, for some reason (e.g. not allowed)
      Allowed values:
    • "Stopping"
    • "NoModulesToStop"
    • "Rejected"
  • StartModulesResultEnum
    string

    Possible results for start module requests

    • Starting: Accepted and modules are commanded to start but haven't done so yet
    • Restarting: Modules are commanded to stop and will be commanded to start once they have stopped
    • NoConfigToStart: Accepted, but there is no configuration slot marked to boot from
    • Rejected: Rejected, for some reason (e.g. not allowed)
      Allowed values:
    • "Starting"
    • "Restarting"
    • "NoConfigToStart"
    • "Rejected"
  • ModuleExecutionStatusEnum
    string

    State of the modules

    • Running: Modules are running
    • NotRunning: Modules are not running
    • Starting: Transitional state Stopped->Running
    • Stopping: Transitional state Running->Stopped
    • FailedToStart: A start/restart was accepted but the configuration failed to validate, so the modules stayed stopped
    • RestartTriggered: Indicates immediately if a restart is intended
      Allowed values:
    • "Running"
    • "NotRunning"
    • "Starting"
    • "Stopping"
    • "FailedToStart"
    • "RestartTriggered"
  • object

    Result when requesting to stop the modules

  • object

    Result when requesting to start the modules

  • ConfigurationApiAvailability
    string

    Availability of the configuration_API

    • N_A: Not available
    • RO: Available, read-only
    • RW: Available, read-write
      Allowed values:
    • "N_A"
    • "RO"
    • "RW"
  • object

    Execution status summary. Will include all the optional fields, if everest_running is true. A false everest_running carries no other field: the manager publishes exactly this payload when it shuts down, and registers it as its MQTT last will for the case where it dies before getting that far.

  • object

    Version designators of the running EVerest instance