SPEKTRA Edge Devices Service API

Understanding the Devices service API.

Devices service manages the edge devices connecting to the SPEKTRA Edge system. The service is typically operated by a user with the device-operator role or a higher.

Full API Specifications (with resources):

Device Management (Device Resources)

Devices on SPEKTRA Edge have their information managed by Device resources. Configuration values and status information for each device are stored in the Device resource. This resource is used by the agent running on the device where the SPEKTRA Edge OS is installed.

Devices are usually managed by being tied to a service account. When the actual SPEKTRA Edge device boots, the agent in the device connects to the Devices service using the stored service account. By using the service account associated with the device resource, it determines which device resource to download configuration values from and stores status information for that device resource.

The simplest Device resource can be created with the following command; since the Device resource is a Project scope resource, the Project must be specified for creation.

## Create a device with ID DEVICE
## display name is "Test Device
cuttle devices create device --project $PROJECT \
  --display-name "Test Device" \
  $DEVICE

Device Metrics

The SPEKTRA Edge device periodically reports hardware metrics information (e.g., CPU utilization), which is stored as time-series data on the Monitoring service; see the Monitoring chapter for instructions on how to use the Monitoring service.

Device Logs

Logging from an SPEKTRA Edge device can be done in two ways: logs from the point of command execution can be streamed in real time via the SPEKTRA Edge controller, or logs sent by the device can be stored in the SPEKTRA Edge backend and retrieved from there as needed. The other is to store the logs sent by the device in the SPEKTRA Edge backend and retrieve the logs from there as needed.

To use the former real-time device logs, use the command:

cuttle devices logs --follow`

In this case, the system logs from the time the command was executed (as described in /var/log/syslog) can be obtained without any additional configuration.

cuttle devices logs --follow $DEVICE

The latter, which stores logs in the SPEKTRA Edge backend and retrieves data from it, requires prior configuration to enable the feature. This feature is currently available without additional subscription, but may be paid for in the future. Log data is stored for up to 90 days.

To perform logging, set the spec.loggingConfig field in the Device resource.

cuttle devices update device $DEVICE_ID \
  --update-mask spec.loggingConfig \
  --spec '{"loggingConfig": {"enableJournalExport": true, "priority":7}}'
Field Description
enableJournalExpor Set to ture to save logs.
priority Set the Priority (level) of logs to be retrieved. Possible values are 1 to 7, according to the Priority of Journald (0 - emergency, 1 - alert, 2 - critical, 3 - error, 4 - warning, 5 - notice,6 - informational, 7 - debug). If a higher Priority is specified, all logs of the lower Priority will also be collected (setting 7 means all logs will be collected).
units Specifies the Systemd unit names of logs to be retrieved. If not specified, logs of all units are acquired. It is omitted in the above example. If you want to use it, add the value to spec.loggingConfig using the following example.

To get docker.service and droplet.service only:

{"units": ["docker.service", "droplet.service"]}

Use the cuttle devices logs --archival command to retrieve the stored logs.

    cuttle devices logs --archival --since 60 $DEVICE_ID
Options Description
--since Specifies when to start logging in seconds. If 60 is used as in the example, logs will be taken from one minute ago to the present.

Remote terminal access to SPEKTRA Edge devices

SPEKTRA Edge devices provide remote terminal access as standard.

For macOS and Linux environments

In macOS and Linux environments, the cuttle command can be used to remotely login to a device. The cuttle devices ssh command is used for terminal access. The argument of the command is the value of NAME as displayed in cuttle devices list devices.

The following is an example of access when NAME is projects/$PROJECT/regions/eu1/devices/test-device.

cuttle devices ssh projects/$PROJECT/regions/eu1/devices/test-device

For Windows environment

The cuttle devices ssh command cannot be used as-is in a Windows environment due to technical limitations. Please refer to the official Microsoft documentation on how to install WSL2.

Port forwarding with SPEKTRA Edge devices

To use a device with SPEKTRA Edge OS installed as a “jump box”, use the cuttle devices forward-port command.

The following example forwards local port 8080 to port 80 on 192.168.10.1 using the device projects/$PROJECT/regions/eu1/devices/test-device as a jump box. With this command running, open localhost:8080 in your web browser to access 192.168.10.1:80 (you will normally see the home gateway operation screen).

cuttle devices forward-port \
  projects/$PROJECT/regions/eu1/devices/test-device \
  8080 tcp://192.168.10.1:80/

Device Auto-registration Settings (Provisioning Policy)

Device resources can be created individually by users, but this can be complicated if there are many devices. To solve this problem, a mechanism to automatically register devices can be used.

The Provisioning Policy resource is a resource that stores settings for auto-registering devices. When an SPEKTRA Edge device with a Provisioning Policy set is booted, a corresponding Device resource is automatically created based on the settings.

Like the Device resource, the SPEKTRA Edge device identifies a Provisioning Policy tied to it using a service account. See the “Provisioning SPEKTRA Edge Devices” section for specific instructions for tying service accounts.

The following example is a cuttle command that creates a new Provisioning Policy.

cuttle devices create provisioning-policy \
  --project $PROJECT \
  --spec '{"mode": "UNATTENDED", \
           "identityFieldPaths": ["status.deviceInfo.hardwareInformation.system.serialNumber"]}' \
  test-provisioning-policy
Field Description
.spec.mode Specifies the registration mode. You can select either UNATTENDED (fully automatic) or MANUAL (with approval). When the registration mode is MANUAL, a Provisioning Approval Request resource is created for approval instead of a Device resource when a new SPEKTRA Edge device is started.
.spec.identityFieldPaths Sets the field used to recognize identical devices. If this field is not set, a Device resource will be created each time the same hardware makes multiple registration requests (for example, when an SD card is remade). By setting this field to include a serial number, an existing Device resource can be reused if a request is made by hardware with the same serial number.

Device resource template values

The Provisioning Policy generates a Device resource for each new hardware. At this time, by setting a value in the Provisioning Policy’s spec.template, it is possible to automatically set the value of the Device resource to be generated.

The following example shows the configuration of a Provisioning Policy when labels and log settings are automatically configured for the generated Device resource.

cuttle devices create provisioning-policy \
  --project $PROJECT \
  --spec '{"mode": "UNATTENDED", \
           "identityFieldPaths": ["status.deviceInfo.hardwareInformation.system.serialNumber"], \
           "template": {"metadata": {"labels": {"device": "raspberry-pi"}}, \
                        "spec": {"loggingConfig": {"priority":7, \
                                                   "enableJournalExport":true}}}}' \
  test-provisioning-policy

SPEKTRA Edge Device Provisioning

Download SPEKTRA Edge OS image

SPEKTRA Edge OS can be downloaded from the following URL. Note that the files used depend on the architecture of the hardware used. Currently, amd64 (x86) or Raspberry Pi 4 are supported.

The image of version 2.1.0 can be downloaded from the following URL

SPEKTRA Edge OS Image Customization

The SPEKTRA Edge OS provided to the public does not contain information tied to a specific Project. Therefore, to automate provisioning, the OS image must be customized and a configuration file must be inserted.

Create a configuration (Provisioning Policy) for automatic registration

Create a Provisioning Policy on the Devices endpoint to configure how new devices will be registered with the system. When a new device is registered with the system, a Device resource is created for each device based on the settings in this resource.

cuttle devices create provisioning-policy \
  --project $PROJECT \
  --spec '{"mode": "UNATTENDED", \
           "identityFieldPaths": ["status.deviceInfo.hardwareInformation.system.serialNumber"]}' \
  test-provisioning-policy

Generate service account and key for Provisioning Policy

In order for a new device to register using the above Provisioning Policy, it must use the service account (and its key) associated with the applicable Provisioning Policy.

The following command generates a service account and stores the downloaded key in /tmp. The jq command is used to format some values.

cuttle devices provision-service-account-to-provisioning-policy \
  -o json \
  provisioning-policy \
  --name projects/$PROJECT/regions/us-west2/provisioningPolicies/test-provisioning-policy | \
jq .serviceAccount > /tmp/service_accont_key.json

Customize image files

Customize the downloaded SPEKTRA Edge OS image using the following command. This command must be used with sudo on Linux.

sudo -E cuttle os edit \
  --image-file lqd_1.0.2.raw
  --password $PASSWORD \
  --endpoint-domain stg01b.edgelq.com \
  --project-service-account-key /tmp/service_accont_key.json

The main options available with the cuttle os edit command are

Options Description
--password Password to use for terminal login.
--endpoint-domain The endpoint domain to connect to. You do not need to specify this if you are using a commercial environment. In the above example, the staging environment is set as the connection destination.
--project-service-account-key The service account key generated by the above method.
--disk-mapping Specify a configuration file to mount internal HDD or SSD.
--ntp Specify the configuration file for NTP server.
--network-agent Specifies the network configuration file.

--disk-mapping: disk mapping file

The disk mapping file is written in YAML format and is configured when using HDDs or SSDs other than the boot media. If you use only boot media, you do not need to specify this option.

The file contents are largely divided into diskmappings and bindmounts, the former being partition mount settings and the latter being bind mount settings.

The diskmappings specifies which disk (disk) and where (mountpoint) it should be mounted. If the partition is unformatted, it will be automatically formatted using the specified size (size) and file system (filesystem). Note that if you specify -1 for the size option, all available space will be used, but only for the tailmost partition.

The bindmounts lists which directories (mountsource) are to be bind-mounted where (mountpoint).

Below is the default disk mapping file for x86 devices. By default, the tailmost EDGELQ_DATA partition is expanded to its maximum size at SPEKTRA Edge OS startup. Also, /var/lib/docker, /var/lib/droplet, and /var/log are bind-mounted in /isodevice/data where EDGELQ_DATA is mounted, so that files stored in these directories will be boot persistent in the media.

Note that the default disk mapping file has different settings for each platform. For example, the Raspberry Pi requires a separate partition to store firmware, etc., so a dedicated setting is used.

diskmappings:
  - disk: /dev/disk/by-partlabel/EDGELQ_DATA
    mountpoint: /isodevice/data
    size: -1
    filesystem: ext4
  - disk: /dev/disk/by-partlabel/EDGELQ_ISOS
    mountpoint: /isodevice/isos
    filesystem: ext4
  - disk: /dev/disk/by-partlabel/EDGELQ_BOOT
    mountpoint: /isodevice/boot
    filesystem: ext4
bindmounts:
  - mountsource: /isodevice/data/docker
    mountpoint: /var/lib/docker
  - mountsource: /isodevice/data/droplet
    mountpoint: /var/lib/droplet
  - mountsource: /isodevice/data/log
    mountpoint: /var/log

--network-agent: network configuration file

The network configuration file is the Netplan configuration file. The default configuration file has DHCP enabled, so there is no need to specify this option if static IP or WiFi settings are not required.

The following is the default configuration file.

network:
  version: 2
  renderer: networkd
  ethernets:
    default-en:
      match:
        name: en*
      dhcp4: yes
    default-eth:
      match:
        name: eth*
      dhcp4: yes

Static IP Configuration Example

The following configuration example sets 192.168.1.30/24 for the eth0 interface.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:
      dhcp4: no
      addresses: [192.168.1.30/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [192.168.1.1]

Example of WiFi setup

The following setup connects the wlan0 interface to the NTT-WIFI network (SSID) using WIFI-PASSWORD as the password.

network:
  version: 2
  renderer: networkd
  wifis:
    wlan0:
      dhcp4: yes
      access-points:
        "NTT-WIFI":
          password: "WIFI-PASSWORD"

Please refer to the Netplan manual for other possible settings (some settings are not supported).

--ntp: NTP configuration file

The NTP configuration file is the systemd-timesyncd configuration file. Specify this option if you want to use an NTP server other than the default.

For information on how to write the configuration file, see man timesyncd.conf or Arch Linux website.

If the NTP server is not properly configured, the SPEKTRA Edge OS and applications running on it may stop working. If a TLS (HTTPS) certificate verification error occurs, make sure that the NTP server is properly configured and that the system clock is not out of sync.

Write SPEKTRA Edge OS to media

Image files can be written to media with any application.

On Linux, for example, you can use the dd command (replacing sdX with the appropriate device name).

sudo dd if=lqd_1.0.2.raw of=/dev/sdX

In a Windows environment, Raspberry Pi Imager or Balena Etcher can also be used.

SPEKTRA Edge Device Startup

The media on which the customized OS image is written can be used as boot media without modification. When the device is booted while connected to the network, it is automatically registered to the SPEKTRA Edge controller.

The list of registered devices can be viewed with the following command

cuttle devices list devices --project $PROJECT

Hardware update procedure

This section describes how the operation is performed in the event of a hardware failure, assuming that the device has been provisioned using a Provisioning Policy, and that the relevant Provisioning Policy has a Deduplication Field with a serial number set.

How to respond to hardware failure

Hardware failure can be divided into two categories: failure of the boot media (SD card or USB memory) on which the SPEKTRA Edge OS is installed, and failure of the hardware itself (such as the Raspberry Pi). Depending on which of these two elements is being replaced, the method of response will vary.

If only the hardware is replaced and the OS media is identical

Insert the existing boot media into the new hardware and boot. In this case, the service account information remaining on the boot media takes precedence over the serial number, so the existing Device resource is used as is (the resource serial number is overwritten).

If the hardware is identical and only the OS media is replaced

Point the new boot media to the existing hardware to boot. In this case, the new boot media does not have a service account to identify the Device resource, so the serial number is used to identify the existing Device resource. Since there is no change in the serial number on the same hardware, the existing Device resource will be used.

When replacing both hardware and OS media

If both are replaced at the same time, a new Device resource will be created since there is no way to identify the existing Device resource. To avoid this behavior, perform the following operations on the OS image (after copying the files) before writing to the SD card.

## remove an existing service account
cuttle devices remove-service-account-from-device device --name $DEVICE
## edit the image file (create service account for the device in question and
## write it)
cuttle os edit cuttle os edit \
  --image-file $IMAGE_FILE_NAME \
  --device-name $DEVICE

Understanding the devices.edgelq.com service APIv1, in proto package ntt.devices.v1.

Understanding the devices.edgelq.com service APIv1alpha2, in proto package ntt.devices.v1alpha2.