"Layers needed" progress should show in `bootc status`

[castrojo]

The progress meter resets for each layer, making it tough for me to see overall progress.

# bootc switch ghcr.io/ublue-os/bluefin-dx:latest
layers already present: 6; layers needed: 62 (4.1 GB)
 12.91 MiB [████████████░░░░░░░░] (0s) Fetching ostree chunk sha256:b3f76892abb7 (22.1 MB)

I know that each layer will be different but maybe a [1/62] and so on would at least show the completion of each layer.

[antheas]

Seconding that and adding:

1. pulling the layers accounts for around 1/3 of update time (fast connection)
2. therefore, installation part needs a progress bar too
3. There should be an overall progress bar, with say nesting

Overall installation progress bar should have a percentage dedicated to pulling layers (e.g., x=40%) and one to installing (e.g., y=60%)

The program is aware of the layer sizes, therefore it can do the following:

DL_WEIGHT = 0.4

def progress():
    total_size = sum([l.size() for l in layers if not l.downloaded()])
    if step == "pulling":
        return DL_WEIGHT * curr_layer.progress() * (curr_layer.size() / total_size)
    else:
        completed = sum([l.size() for l in layers if l.applied()])
        return DL_WEIGHT + (1 - DL_WEIGHT) * (completed / total_size)

In addition, while its nice to view in a tty, programs should be able to take advantage of this too. Therefore, there should be a --guided option that 1) disables the progress bars 2) redirects progress to stderr such as with:

TOTAL_WEIGHT = 10000

def progress_stderr():
    p = progress()
    return f"{int(p*TOTAL_WEIGHT)}/{TOTAL_WEIGHT}\n"

Stdout should only have the logs, so they can 1) be logged for transparency and 2) optionally shown to the user. Also, current version eats the update log. It needs to say Chunk sha256:x (x/N) downloaded/applied without erasing it once it progresses (see docker logs).

The cherry on top would be if there is an estimated time in this too. It is easy to do for the download, perhaps not so much for application. Perhaps assuming the user has a 10gbit SSD and returning a constant time left based on update size during application?

I also saw the current backend essentially marshals libostree and unlike rpm-ostree implements the libostree progress listener. So there's a chance this needs to be triaged with libostree but maybe not.

[travier]

Initial start in #472 (needs rework). My bad, this is about progress.

[cgwalters]

#524 will add the layer counts to progress.

[cgwalters]

I think #524 fixes the initial request here.

therefore, installation part needs a progress bar too

Yes, I'd agree, though there's a good bit more involved there at a technical level right now, and I think it's going to need to slot behind other things. For now, closing the original bug here as fixed, but we will clearly revisit progress bars after more infra work has landed.
(In particular I actually want to focus on making "installation" more efficient, not just showing progress, which is more in the domain of #215 and ostreedev/ostree-rs-ext#11 )