mender-artifact should inform the user that certain commands can take a long time

Description

Certain commands of mender-artifact, e.g "cp" can take very long time if the artifact/image is large but users are not informed and one can easily think that the tool might have hanged.

Some additional background can be found here

Acceptance criteria:

  • mender-artifact should inform the user that command (commands known to take long time) can take several minutes to complete

Affects versions

None

Environment

None

Checklist

Activity

Show:

Ole Petter Orhagen December 2, 2020 at 10:23 AM

A progressbar has now been added to

  • write

  • read

Which I think are good first steps. For validate, and sign I think this can be added too, with not too much effort. cp, modify and cat I'm not sure. I'll have to investigate a bit.

Kristian Amlie July 3, 2019 at 8:04 AM

I think this isn't terribly difficult, we know most of the sizes involved, but there is some rewriting and hooks we need to implement. The existing progress bar is not reusable, because it measures the size of an existing artifact (the compressed .mender file), which obviously isn't known in a writing situation until afterwards. This also leads to quite wrong estimations (99% takes 50% of the time, then the last 1% takes 50% of the time due to highly compressed null bytes), so rewriting it to take actual uncompressed sizes into account would be an improvement.

I'd say something along the lines of 21SP for the whole thing, no extra tasks involved.

eystein.maloy.stenberg June 27, 2019 at 5:17 PM

OK! Yes, as a general rule of thumb in UX, if an operation takes more than 10 seconds there should be a progress indicator.
So the progress on the payload would probably be enough. I know we have progress bar on the client when running in standalone mode, not sure if that is reusable..

But let's also get input from on the feasibility of this. If involved we should just add a general message with some potential ballpark time (perhaps depending on input size).

Ole Petter Orhagen June 27, 2019 at 8:13 AM

Hi .

I don't have any deep insights into this at the moment, but in general, they are writing – one, a tar of tars, and two – a sdimg partition (or multiple). 

In general, I think the easiest solution would be to simply write some progress messages to stderr.

If we decide to go for a more involved solution then in general I do not think we can rely on any sort of progress measure from the tar writer, as there are a lot of tars written, so maybe checkpointing could be an idea? Still, what takes the longest time is writing the actual payload I guess, so maybe this is all we should have a progress measure on?
For an sdimg this is probably a bit more straight forward.

However I do not have any deep insights into this, and all insights, tips and ideas are welcome. Also if cared to look it over I'd be happy.

eystein.maloy.stenberg June 26, 2019 at 10:24 PM
Edited

Thanks , yes I have experienced this myself and it can be quite annoying (and surprising to first-time users, seemingly something is wrong).

After looking at the commands in mender-artifact, I think actually all of them can take a very long time, they all seem to be linear with the size of the .sdimg/.mender file:

what are your thoughts on this? Ideally we can make these operations faster, but that is not feasible for all cases at least (if any).

What do you think about adding some kind of progress bar, is that possible for some / most of them?

Details

Assignee

Reporter

Priority

Days in progress

Backlog

Zendesk Support

Checklist

Created June 26, 2019 at 6:56 AM
Updated June 25, 2024 at 12:02 PM