-X DELETE returns 204; Client/Platform doesn't Update

General Discussions
1

Working with the API via Bash scripting.

Using the following code to Dismiss (delete) a device

  local url="$BASE_URL/api/management/v1/inventory/devices/$device_id"
  local tmp_response=$(mktemp)

  log "INFO" "Trying to dismiss device $device_id (auth: $auth_id)"

  local status_code=$(curl -s -o "$tmp_response" -w "%{http_code}" -X DELETE "$url" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $MENDER_TOKEN" )

The mktemp is for logging purposes

Created logging which returns the following:

[INFO] [Trying to dismiss device [device-id] (auth: [auth-id])]
[INFO] [✅ Request succeeded: HTTP 204]

Device does not update. The GUI does not reflect this change.

Tried multiple times over the course of a day, with same results.

Logs on the device itself also do not update when sending the DELETE request

Can go into the GUI and Dismiss from there, and the device moves from “Accepted” to “Noauth” to “Pending” within a minute.

Logs on device do update when Dismissing via the GUI

From another Bash script, I can accept the device, which is also successful, and the GUI and device info updates almost immediately, but attempting to Dismiss (delete) from CLI still doesn’t take.

For insight, logs on device do not update when sending an Accept request from the API

Is there something I am missing here? Am I using the API wrong or the wrong part of the API to do this?

2

Hi @jj_menderio,

I think you’re basically on the right track. However there is one thing to note here. There is a difference between “dismissing” and “decommissioning” a device. The former deletes a specific certificate which the device has provided for authentication, while the latter completely removes the device from the fleet. The API endpoint is Mender API docs.

Note though, that decommissioning a device will only work in a meaningful way if the device also has been disabled and stopped its connection attempts to the backend, otherwise it will just reappear as pending upon the next cycle.

Greetz,
Josef

3

Thank you for taking the time to respond.

Could you tell me how “dismissing” and “decommissioning” relate/differ and function within the context of the DELETE command of the API?

Could you also expand upon that to help me understand if I am using DELETE in the correct way, and if so, why I am experiencing no update though I am receiving a successful 204?

4

Hi @jj_menderio,

So for the API side:

  • “dismissing” means that an auth(entication) set is removed. The endpoint is Mender API docs
  • “decommissioning” means that the device and all of its auth sets are removed. The endpoint is Mender API docs

Concerning the changes being visible in the UI, my guess is that when you trigger a change there, then the web UI refreshes relatively soon, whereas without interaction and the changes happening through the API the next refresh might take some time.

What do you mean by “logs on the device do update”? My understanding is that those should reflect the change upon next polling cycle in both cases.

Greetz,
Josef

5

…whereas without interaction and the changes happening through the API the next refresh might take some time.

Would you think 8+ hours might be too long of a time to wait?

What if I told you rebooting the device and restarting the mender process also didn’t update the UI nor the API pull requests (as in, after receiving the 204 Confirmation, and waiting, and rebooting the device, and restarting the process, the API GET commands still show the Device as Accepted)?

What do you mean by “logs on the device do update”? My understanding is that those should reflect the change upon next polling cycle in both cases.

When tailing journalctl for mender updates, logs will appear when Dismissing via the Web based GUI.
Logs do not update when a DELETE command is sent via the API, nor do they appear when submitting a GET command via the API to update the “status” to “accepted”.

6

Also, thank you for those links, as it helps provide clarity, and looking at them makes me think we have different understandings:

  • What you list as Dismissing, I understand it as Decommissioning
    • curl -X DELETE https://hosted.mender.io/api/management/v2/devauth/devices/{id}
  • What you listed as Decommissioning, I understand it as Rejecting
    • curl -X DELETE https://hosted.mender.io/api/management/v2/devauth/devices/{id}/auth/{aid}

And if my understanding is correct of those two previous, this is my understanding of Dismissing

curl -X DELETE https://hosted.mender.io/api/management/v1/inventory/devices/{id}
7

Hi @jj_menderio

Nope that’s definitely too long. I would expect it to show the change within 5-10 minutes.

Then I can just conclude that there is something else that we’re not seeing yet unfortunately, sorry.

Greetz,
Josef

8

Hi @jj_menderio :wave:

And if my understanding is correct of those two previous, this is my understanding of Dismissing

curl -X DELETE https://hosted.mender.io/api/management/v1/inventory/devices/{id}

This assumption is not correct. The above API is clearing the inventory attributes from a device, that is, the data submitted by the device to the inventory APIs. The other two devauth APIs are managing the device’s authentication data (think of it as the device’s certificate, it consist of the data identifying the device and an asymmetric key proving ownership).

As I can see there are some misuse of the term “rejecting” in the API documentation, let me see if I can rephrase it:

  • Rejecting a device is calling the [Set Authentication Status](https://docs.mender.io/api/#management-api-device-authentication-set-authentication-status) API with status rejected`
  • Decommissioning a device is calling the Decommission Device API
  • Dismissing a device is calling the Reject (remove) authentication API
9

Thank you for jumping in and providing more clarity.

And yes, the docs are a bit confusing regarding rejecting, decommissioning, and dismissing.

For further clarification, if I want to “Dismiss” a device, I would follow the last Bullet:

Dismissing a device is calling the Reject (remove) authentication API

This should allow me to remove a device from Accepted without removing it’s history, and then later re-Accept it when desired.

Is that accurate?