Retrieving information about SPS firmware image slots
Retrieve information about SPS firmware images maintained on the device in locations called slots.
URL
GET https://<IP-address-of-SPS>/api/firmware/slots
Cookies
| session_id |
Contains the authentication token of the user |
Required |
The value of the session ID cookie received from the REST server in the authentication response, for example, a1f71d030e657634730b9e887cb59a5e56162860. For more information on authentication, see Authenticate to the SPS REST API.
NOTE: This session ID refers to the connection between the REST client and the SPS REST API. It is not related to the sessions that SPS records (and which also have a session ID, but in a different format). |
Operations
Operations with the /firmware/slots endpoint include:
|
Retrieving information from firmware image slots |
GET |
/api/firmware/slots |
|
|
Retrieving information from a specific firmware image slot |
GET |
/api/firmware/slots/<slot_id> |
Example:
/api/firmware/slots/1 |
|
Deleting a firmware image slot |
DELETE |
/api/firmware/slots/<slot_id> |
NOTE: Deleting the current firmware, or the one after the reboot, is not allowed. |
Sample request
The following command lists all available firmware image slots.
curl --cookie cookies https://<IP-address-of-SPS>/api/firmware/slots
Response
The following is a sample response received if the request was successful.
For more information on the meta object, see Message format.
{
"items": [
{
"body": {
"after_reboot": false,
"current": true,
"upgrade_news": null,
"upgrade_notes": "some notes",
"version": "6.5.0"
},
"key": "1",
"meta": {
"href": "/api/firmware/slots/1"
}
},
{
"body": {
"after_reboot": true,
"current": false,
"upgrade_news": null,
"upgrade_notes": "some notes",
"version": "6.6.0"
},
"key": "2",
"meta": {
"href": "/api/firmware/slots/2"
}
},
{
"body": {},
"key": "3",
"meta": {
"href": "/api/firmware/slots/3"
}
},
{
"body": {
"after_reboot": false,
"current": false,
"upgrade_news": null,
"upgrade_notes": "some notes",
"version": "6.7.0"
},
"key": "4",
"meta": {
"href": "/api/firmware/slots/4"
}
},
{
"body": {},
"key": "5",
"meta": {
"href": "/api/firmware/slots/5"
}
}
],
"meta": {
"current_slot": "/api/firmware/slots/1",
"href": "/api/firmware/slots",
"number_of_empty_slots": 2,
"parent": "/api/firmware",
"slot_after_reboot": "/api/firmware/slots/2"
}
}
The following is a sample response received when a specific firmware image slot is listed.
{
"body": {
"after_reboot": false,
"current": true,
"upgrade_news": null,
"upgrade_notes": "some notes",
"version": "6.5.0"
},
"key": "1",
"meta": {
"href": "/api/firmware/slots/1",
"parent": "/api/firmware/slots"
}
}
Elements of the response message body include:
|
after_reboot |
boolean |
This flag shows that the firmware is selected to be the active firmware after upgrade. |
Possible values:
|
|
current |
boolean |
Indicates whether the firmware is active. |
Possible values:
|
|
upgrade_news |
string |
Displays SPS Upgrade Notes that is relevant to the current firmware. |
If there is no such information available, the value will be null. |
|
upgrade_notes |
string |
The content of the SPS Upgrade Notes. |
|
|
version |
number |
The version number of that specific SPS firmware image. |
|
HTTP response codes
For more information and a complete list of standard HTTP response codes, see Application level error codes.
Testing new SPS firmware before upgrade
Use the /firmware/test endpoint as a precheck tool to trigger an upgrade test without an actual upgrade. The test reveals whether the current state of SPS is compatible with the new firmware. Possible areas where errors can occur:
-
version compatibility - the new firmware is compatible with the upgrade policy
-
storage space - there is enough free storage space for the upgrade
-
configuration compatibility - the current configuration settings are supported in the new firmware
-
tainted firmware - whether or not there are manually modified files on the firmware
URL
POST https://<IP-address-of-SPS>/api/firmware/test
Cookies
| session_id |
Contains the authentication token of the user |
Required |
The value of the session ID cookie received from the REST server in the authentication response, for example, a1f71d030e657634730b9e887cb59a5e56162860. For more information on authentication, see Authenticate to the SPS REST API.
NOTE: This session ID refers to the connection between the REST client and the SPS REST API. It is not related to the sessions that SPS records (and which also have a session ID, but in a different format). |
Operations
Operations with the /firmware/test endpoint include:
|
Testing new SPS firmware before upgrade |
POST |
/api/firmware/test |
|
Sample request
The following command triggers a firmware upgrade test.
curl --cookie cookies https://<IP-address-of-SPS>/api/firmware/test --data '{"slot_id": <slot_id>}'
NOTE: You require a payload first, from which you choose the firmware you want to test.
Response
There can be three possible outcomes:
-
the upgrade was successful:
{"body": "...", "key": <slot_id>}
-
the upgrade was not successful due to invalid input:
-
the slot_id is missing from the payload
{"error": {"type": "IncompleteRequestBodyError"}}
-
the tested firmware slot is empty
{"error": {"type": "ResourceNotFound"}}
-
the upgrade was not successful due to an error:
{"error": {"type": "FirmwareTestFailed"}}
The following is a sample response received when the upgrade test was successful.
For more information on the meta object, see Message format.
{
"body":
{ "test_summary": "HA check started\nHA check finished" },
"key": "1",
"meta": {
"href": "/api/firmware/test",
"parent": "/api/firmware",
"slot": "/api/firmware/slots/1",
"upgrade": "/api/firmware/upgrade"
}
}
The following is a sample response received when the upgrade test was not successful, because the firmware slot is empty.
{
"error": {
"details": {
"mount_point": "/firmware/test",
"resource": "3"
},
"message": "Resource was not found",
"type": "ResourceNotFound"
},
"meta": {
"href": "/api/firmware/test",
"parent": "/api/firmware"
}
}
Elements of the response message body include:
|
error.details |
object |
|
|
|
error.details.mount_point |
string |
The reference point - in this case a URL path - at which details of the error can be accessed. |
This is a fix value: /firmware/test |
|
error.details.resource |
number |
The identifier of the firmware image slot. |
|
|
error.message |
string |
The content of the error message. |
|
|
error.type |
string |
The type of the error message. |
|
The following is a sample response received when the upgrade test was not successful, because the slot_id is missing from the payload.
{
"error": {
"details": {
"missing_paths": [
"slot_id"
]
},
"message": "Some paths were missing from the request body",
"type": "IncompleteRequestBodyError"
},
"meta": {
"href": "/api/firmware/test",
"parent": "/api/firmware"
}
}
Elements of the response message body include:
|
error.details |
object |
|
|
|
error.details.missing_paths |
array |
A list of missing URL path parameters. |
In this case, there can be only one value here, which is slot_id. |
|
error.details.missing_paths.slot_id |
|
The identifier of the firmware image slot. |
|
|
error.message |
string |
The content of the error message. |
|
|
error.type |
string |
The type of the error message. |
|
The following is a sample response received when the upgrade test was not successful, because an error was found during testing.
{
"error": {
"details": {
"exit_code": 1,
"test_summary": "HA check started\nHA check failed"
},
"message": "The firmware test failed",
"type": "FirmwareTestFailed"
},
"meta": {
"href": "/api/firmware/test",
"parent": "/api/firmware"
}
}
Elements of the response message body include:
|
error.details |
object |
|
|
|
error.details.exit_code |
number |
|
Possible values:
|
|
error.details.test_summary |
string |
The summary of the upgrade test in free text format. |
For example:
HA check started,
HA check failed |
|
error.message |
string |
The content of the error message. |
|
|
error.type |
string |
The type of the error message. |
|
HTTP response codes
For more information and a complete list of standard HTTP response codes, see Application level error codes.
Upgrading SPS to a new firmware
Use the /firmware/upgrade endpoint to upgrade SPS to a new firmware.
URL
POST https://<IP-address-of-SPS>/api/firmware/upgrade
Cookies
| session_id |
Contains the authentication token of the user |
Required |
The value of the session ID cookie received from the REST server in the authentication response, for example, a1f71d030e657634730b9e887cb59a5e56162860. For more information on authentication, see Authenticate to the SPS REST API.
NOTE: This session ID refers to the connection between the REST client and the SPS REST API. It is not related to the sessions that SPS records (and which also have a session ID, but in a different format). |
Operations
Operations with the /firmware/upgrade endpoint include:
| Upgrading SPS to a new firmware |
POST |
/api/firmware/upgrade |
|
Sample request
The following command upgrades SPS to a new firmware.
curl --cookie cookies https://<IP-address-of-SPS>/api/firmware/upgrade --data '{"slot_id": <slot_id>, "message": "..." | null}'
NOTE: The value of message can be null, if require_commit_log is disabled. If require_commit_log is enabled, then message is filled.
Response
There can be three possible outcomes:
-
the upgrade was successful:
{"body": "...", "key": <slot_id>}
-
the upgrade was not successful due to invalid input:
-
the slot_id is missing from the payload
{"error": {"type": "IncompleteRequestBodyError"}}
-
the tested firmware slot is empty
{"error": {"type": "ResourceNotFound"}}
-
the upgrade was not successful due to an error:
{"error": {"type": "FirmwareTestFailed"}}
The following is a sample response received when a SPS is upgraded to a new firmware.
For more information on the meta object, see Message format.
{
"body":
{ "test_summary": "HA check started\nHA check finished" },
"key": "1",
"meta": {
"href": "/api/firmware/upgrade",
"parent": "/api/firmware",
"slot": "/api/firmware/slots/1"
}
}
The following is a sample response received when a firmware upgrade is attempted on an empty slot.
{
"error": {
"details": {
"mount_point": "/firmware/upgrade",
"resource": "3"
},
"message": "Resource was not found",
"type": "ResourceNotFound"
},
"meta": {
"href": "/api/firmware/upgrade",
"parent": "/api/firmware"
}
}
Elements of the response message body include:
| error.details |
object |
|
|
|
error.details.mount_point |
string |
The reference point - in this case a URL path - at which details of the error can be accessed. |
This is a fix value: /firmware/upgrade |
|
error.details.resource |
number |
The identifier of the firmware image slot. |
|
|
error.message |
string |
The content of the error message. |
|
|
error.type |
string |
The type of the error message. |
|
The following is a sample response received when message is missing from the request body during upgrade.
{
"error": {
"details": {
"missing_paths": [
"message"
]
},
"message": "Some paths were missing from the request body",
"type": "IncompleteRequestBodyError"
},
"meta": {
"href": "/api/firmware/upgrade",
"parent": "/api/firmware"
}
}
Elements of the response message body include:
| error.details |
object |
|
|
|
error.details.missing_paths |
array |
A list of missing URL path parameters. |
In this case, there can be only one value here, which is message. |
|
error.message |
string |
The content of the error message. |
|
|
error.type |
string |
The type of the error message. |
|
The following is a sample response received when the firmware test fails during upgrade.
{
"error": {
"details": {
"exit_code": 1,
"test_summary": "HA check started\nHA check failed"
},
"message": "The firmware test failed",
"type": "FirmwareTestFailed"
},
"meta": {
"href": "/api/firmware/upgrade",
"parent": "/api/firmware"
}
}
Elements of the response message body include:
| error.details |
object |
|
|
|
error.details.exit_code |
number |
|
Possible values:
|
|
error.details.test_summary |
string |
The summary of the upgrade test in free text format. |
For example:
-
HA check started
-
HA check failed |
|
error.message |
string |
The content of the error message. |
|
|
error.type |
string |
The type of the error message. |
|
HTTP response codes
HTTP response codes comprise of standard or endpoint-specific HTTP status and error codes. The following table lists the endpoint-specific HTTP response codes for this request.
| 400 |
UpgradeMessageMissing |
The upgrade request did not contain a message. Adding a message is required. |
For more information and a complete list of standard HTTP response codes, see Application level error codes.
Uploading new firmware to SPS
Use the /upload/firmware endpoint to upload new firmware to SPS.
URL
POST https://<IP-address-of-SPS>/api/upload/firmware
Cookies
| session_id |
Contains the authentication token of the user |
Required |
The value of the session ID cookie received from the REST server in the authentication response, for example, a1f71d030e657634730b9e887cb59a5e56162860. For more information on authentication, see Authenticate to the SPS REST API.
NOTE: This session ID refers to the connection between the REST client and the SPS REST API. It is not related to the sessions that SPS records (and which also have a session ID, but in a different format). |
Operations
Operations with the /upload/firmware endpoint include:
| Uploading SPS firmware images |
POST |
/api/upload/firmware |
The enctype attribute of the POST request must be multipart/form-data. |
Sample request
The following command uploads a new firmware to SPS.
curl --cookie cookies https://<IP-address-of-SPS>/api/upload/firmware --form firmware=@<sps.iso>
Where <sps.iso> is the path of the new firmware.
Response
The following is a sample response received when a new firmware image is uploaded.
For more information on the meta object, see Message format.
{
"body": {
"after_reboot": true,
"current": false,
"upgrade_news": null,
"upgrade_notes": "some notes",
"version": "6.6.0"
},
"key": "2",
"meta": {
"href": "/api/upload/firmware",
"slot": "/api/firmware/slots/2",
"test": "/api/firmware/test",
"upgrade": "/api/firmware/upgrade",
"number_of_empty_slots": 2
}
}
Elements of the response message body include:
| after_reboot |
boolean |
This flag shows that the firmware is selected to be the active firmware after upgrade. |
In this particular case, the value of after_reboot will always be false, as the firmware has not yet been chosen for upgrade. |
|
current |
boolean |
Indicates whether the firmware is active. |
Possible values:
|
|
upgrade_news |
string |
Displays SPS Upgrade Notes that is relevant to the current firmware. |
If there is no such information available, the value will be null. |
|
upgrade_notes |
string |
The content of the SPS Upgrade Notes for that firmware image. |
|
|
version |
number |
The version number of that specific SPS firmware image. |
|
HTTP response codes
For more information and a complete list of standard HTTP response codes, see Application level error codes.
