Updates report

[doanac]

This helps address issue #71 in a different way that's more useful for someone operating a larger fleet.

Web UI change looks like:

when clicking on a sampling you see:

The CLI looks like:

$ fiocli updates show a a 
# Details
Update: a
Tag: a

# Rollout summary
  Installation completed; failed: 6
  Installation completed; succeeded: 19
  Metadata update completed; failed: 10

# Rollouts: None

# TUF metadata
  Latest target name: aaa-1
...

[doanac]

@MiloCasagrande - FYI - I broke my promise to not add anything else to the webui. However, this is one the most useful things I've implemented in a while.

[doanac]

This was tested using a rollout.log file that was 51Mb: https://dg.gavelci.us/updates/andy-corp-fake/154 . The performance feels acceptable.

[vkhoroz]

It looks good to me.

I only have a question, which I'm sure you'll answer.
There may have been some concerns about performance, but iiuc that's irrelevant until 100K devices per update.

[vkhoroz]

Sorry, I don't quite get how does this work.
May I ask to help me understand?

So, iiuc we read the entire rollout file for events, and store the latest event for each device.
Then, we go through these "latest" events and pick 100 of success/failure (or whetever other status we support).
As Golang maps are not ordered, we get 100 success/failure events for a random set of device uuids each.
These may be the latest statuses, or some old statuses, depending on pure luck.

Maybe, I'm wrong on this; but it looks like we may do a better job.
For example, we may also keep an ordered list of uuids (as they appear in a log), and then range over them in the reverse, so that the "sampling" selects 100 devices with the most fresh events (not 100 random devices) for each status.

A sampling idea seems smart, but it only starts helping after, maybe, 20K devices per update. As uuid is fairly small, even at 10K devices, we get ~300-400K of data (including JSON overhead).

(
fwiw a rollout log is constantly rotated, so that a data in it cannot be considered complete for large datasets.
Just a side note. I think you considered this already.
)

[doanac]

A sampling idea seems smart, but it only starts helping after, maybe, 20K devices per update.

The problem is with the UX of it. What can a user do with 20k UUIDs? Its too much to display and they are going to randomly click on some items. This just saves some memory/response-size.

so that the "sampling" selects 100 devices with the most fresh events

I thought about that a little. I was slightly concerned that by doing this - your sampling may all be the exact same failure whereas this being slightly more random might give you a better overview of the different ways a given update event is showing failures.

Does this make any sense? It could be me justifying being lazy and not thinking hard

[vkhoroz]

I think I'm somewhat convinced that we need this "sampling", as a handy "top N devices with status XYZ".

But, I still have 2 concerns:

• I do agree that showing 20K UUIDs is a nightmare; but 100 UUIDs is not much less an overload.
  If we're talking about a handy UI, I'd limit this to top 5 or maybe top 20 at most.
  Later on, we might have some drill-down to show all devices with the same status as a navigable table.

• When we talk about random vs non-random, I care about reproducibility.
  For example, how are we going to test this thing if the return list is unpredictable?
  Randomness gives us little value here, as for a failed update, 99% of errors will be the same;
  and we're still prone to lose the other 1% regardless of this added randomness.
  The most recent devices to get a given status, in contrast, seem to be the most relevant.

[doanac]

I've just pushed a new change. Things looks similar visually but I've broken up the "summary" API from the api to get the list of devices. Now we can show the full listing when the user wants.