No feedback for long running operation

Bug #1669730 reported by Alan Pope 🍺🐧🐱 🦄
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snapcraft
Fix Released
Medium
Kyle Fazzari

Bug Description

Just ran "snapcraft cleanbuild --remote foo" (where foo is my home server where I like to build things). It's sat at the following:-

"Copying snapcraft cache into container"

For a very long time. I thought maybe the server had died or something, but it hadn't, lxd is eating cpu because it seems that snapcraft is pushing my entire ~/.cache/snapcraft to the remote machine over wifi.

I have no feedback as to what's going on in terms of progress, so don't know how far it's got or when (if) it will finish. Perhaps we need some kind of spinner or progress bar?

(my .cache/snapcraft directory is 2GB in size)

Revision history for this message
Kyle Fazzari (kyrofa) wrote :

Thanks for this, Alan. Most of the size from the Snapcraft cache is stage packages. We really wanted to bind-mount it, but the user mapping in lxd got in the way there so it wouldn't be usable. As a result we ended up copying it, not considering remote cleanbuilds where that would take quite some time.

In your mind, what is the ideal solution in this scenario? A better progress indicator as you suggest? Or no cache copying to remote hosts?

Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) wrote :

I'm not convinced it's worth copying the cache at all. I'm likely to build different things locally than remotely. So locally I might build small / fast / binary-only things. But remotely I might build very long running computationally intensive things. I expect the cache wouldn't be much use in that case, so not much point copying it. For me while remote means "run this and don't care when it finishes or how long it takes", still I don't want it to block on copying tons over the network before it even starts.

Revision history for this message
Kyle Fazzari (kyrofa) wrote :

I'm good with that. At the very least it should be exposed as an option. I'll bring it up in standup.

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

When using --remote should probably we should just not copy this cache at all for now and think of a better UX in the meantime.

Let's just fix this in this bug.

Changed in snapcraft:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Kyle Fazzari (kyrofa)
milestone: none → 2.28
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

I am going to revert the code that does the copy in cleanbuild until a better solution is thought out.

There are many problems when host != xenial

Revision history for this message
Sergio Schvezov (sergiusens) wrote :
Changed in snapcraft:
status: Triaged → In Progress
Changed in snapcraft:
status: In Progress → Fix Committed
Changed in snapcraft:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.