Disk usage report

As a little side effect of thinking about disk usage for out-of-disk-space protection, we’ll be including disk usage in the API and probably exposing it in snap info.

What do you have in mind for that one? Computing $SNAP_DATA and $SNAP_USER_DATA?

Talked to @chipaca on IRC about this. The currently proposed idea is to introduce a new snap command, something in the lines of snap disk-usage [--user=username|uid] [<snap>]. The output should contain a per snap, per revision disk usage report:

<what>             <size>
my-app
  revisions:
   3247            100MB  # SNAP_DATA + squashfs size
   3357            100MB
   3377            100MB
    ...
   common:         12MB   # SNAP_COMMON

  user foo:   
   3247            12MB   # SNAP_USER_DATA
   3357            13MB
   common:         3MB    # SNAP_USER_COMMON

The --user could be passed multiple times, what would result in data for multiple users to be included in the report. Omitting <snap> would produce a report for multiple snaps.

Do we actually want to allow random users to see other random users disk usage ? i think the usage of --user should be restricted to the system admin (root) only…

Yeah, that’s the idea. Being an unprivileged user, you’d only see your data count. As root, you’ll probably be able to see everything.

OTOH, if you, as a user foo, can access a user bar SNAP_USER_DATA, SNAP_USER_COMMON, it might make sense to be able to show the counts too.

One part where it gets tricky is that with the way the daemon handles access the uid/gid of the caller is lost before it gets out to the api handlers. So to do this properly we’d need to change that.

That’s some hairy code, so I’d recommend you make this endpoint have GuestOK and UserOK (and SnapOK) set to false, for a first iteration where only the admin can use this. We can relax that in a followup.

Also, just to be clear, disk-usage is a strawman, and the definitive command name will be discussed in peer review.

@mborzecki @chipaca The availability of the data sounds interesting, but we need to discuss the format some more once we’re closer to implementation. Both in the sense of the format, the command name, and whether we need a new command at all or perhaps this should be added to one of the existing ones behind a specific flag.

While this could go under snap info with a flag, it would need a separate API or API flags because of how expensive calculating this could be.

What about putting this information in the (as of yet undesigned and only mentioned in passing during Paris) snap status command which contains dynamic state about the snap, such as service info, health checks, etc. ?