This topic is just to report a little bug which confused me a lot though and made debugging a bit longer.
Use case: when Client can access the backend but NOT the file storage proxy (for example, outgoing traffic is blocked on port 9000 but allowed on 443 ), UI shows the following when such device is starting update:
which is misleading because in fact if you look at the device logs, download is not even starting.
The device stays in this state for a day retrying until finally reports a failed attempt.
Expected behavior: it should show “Starting Download” or at least “Downloading…0%” during this period.
Tested with mender clients V2.0, backend V2.1 and V2.3.0
This is another issue but also related to the Deployments Page:
Currently, “Started At” timestamp is always the same for all devices across a given deployment and corresponds to the time when deployment was created and NOT when it started for a given device:
(I’m sure that devices on this screenshot haven’t started the update at the same minute)
While it makes more sense, IMO, to show the timestamp of when the device started the update (i.e. when deployment status is switching from “pending” to “downloading” for a given device).
Otherwise, this column brings no useful information to the user, as the timestamp of the beginning of the whole deployment is already shown on deployment info box:
@ster, you can also create a bug directly on https://tracker.mender.io/ but it is always a good idea to discuss here prior to creating the bug report in the tracker as it might already exist tickets for the mentioned or things have might been fixed in master.
The problem with the deployment progress is that the UI doesn’t have all the information the client has, since the client only informs the backend (and this is then shown in the UI) once a stage in the deployment has passed. So especially the download steps only approach what the progress should be - we wouldn’t know when the device actually starts downloading. I’m not sure if the client actually does check in more frequently - maybe @oleorhagen can give some insights here…?
With regards to the second issue, we also rely on the information coming from the API - given the current work on that aspect maybe @tranchitella knows how this will be handled for e.g. dynamic deployments…?
The progress is not possible to get from the client ATM.
This is done on purpose, as the client is supposed to be part of a huge deployment fleet, and you don’t want a million devices constantly bombarding with the progress during the install.
I have been playing with the idea of enabling this as a configuration option though, but I am afraid it would meet some opposition internally.
No problem if it’s not possible. Maybe just remove the progress bar and percentage (just show “Stage X of Y - Downloading”), as otherwise the UI is misleading.
@mzedel@ster with the current implementation, the “started_at” field of the device deployment is to be intended as the date/time when the (whole) deployment has been created. This is going to change with the implementation of dynamic deployments, because the device deployment (the object that is device specific for a given deployment) will be dynamically created when the device asks for the update, not when the deployment is created by the user.
