Inconsistency in hostname display in devices menu in Web UI

We’re having a problem in Mender 2.1.0 with the hostname that shows up in the devices tab. There is an inconsistency between the hostname shown in the device list and the host name shown when the device is clicked. We changed the hostname algorithm with a mender update awhile back and the device list is showing the old hostname for some devices. I’ve attached a picture showing what happens. The hostname is capitalized in the detail screen while it is not in the device list(that is the change we made).

Does anyone have any idea why this might be happening and if there is a way to get the UI to update the devices names it shows in the device list?

You seem to have hostname in both identity and inventory fields. These should be two different scripts on the device, did you update both?

Please take note that changing the identity of the device has some implications as well. There was a recent thread on this topic, Changing device identity after field deployment

At some point I changed the metadata I was sending with the inventory script, and the web UI held on to the most recent value of some fields I was no longer shipping. It seems to me that the web UI shows the most recent value for all key/value pairs it has for a device. I wonder if decommissioning the device and re-adding it will clear out the old state.

@mzedel can you comment on the potential of stale data here? Is this a frontend thing or a database thing?

This is expected. Inventory fields are not removed if you stop sending them.

What @mirzak said seems to be the reason, the previous inventory value still being served from the database.
The frontend should not have any identity or inventory after a browser refresh or - if a single device is concerned - after expanding a device in the device list.

We have the mender-device-identiy scripts and also the mender-network-identity script which both read the hostname from /etc/hostname. We never did decomission the device after the identity change though. It came up again in the client as needing a new auth set without decomissioning it.

So, do I understand correctly that the gui lists devices by identity but the details are from the inventory data? If so, it appears that identity data isn’t getting updated when the devices asks for a new auth set and provides new inventory data?

Hi @ckelloug2 it does not read the inventory data to determine the identity. In your case you have the same key-value pair in both inventory and identity.

@peter @tranchitella do you guys have any idea if this could be getting stale data from the backend?



I can only add that if you want to remove some old inventory data, just send empty values/new values, they will get overwritten.
the identity identifies your device, if it has not been changed, and you still have the same authset then Mender server has no means to determine that it is a different device. The identity data should not change, while the inventory data you can change at will. The authsets are the ones that you really accept/reject/etc.
I hope some of this helps. I do not see the apparent problem. could you state what is exactly wrong here?



We’re doing an update the changes the hostname from lowercase to uppercase due to a requirement in another part of our code. Our big concern is that we don’t want the device to come up as pending again due to the inconsistency between the device identity and the inventory data. Will this happen?

It will for sure end up in “Pending” state again if you change the identity, even if it is a lower case to uppercase change on a name, this will be counted as “new identity” . There is no strict relation between device identity and inventory data, so that they are inconsistent does not matter much.

But I also think I know what is going with the “stale” data. The Mender client sends device identity data together with the authorization request.

What normally happens is:

  1. Mender client sends a authorization request
  2. Device gets authorized on the server
  3. Mender client receives a JWT, which it will use in further communication.

If the device has a valid JWT token (it is valid for a week I think), it will not send any authorization requests, which I think explains why the device identity fields have not yet been updated.