Disk usage report

chipaca 2017-10-05 13:01:53 UTC #1

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.

niemeyer 2017-10-05 17:20:29 UTC #2

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

mborzecki 2017-11-02 14:08:14 UTC #3

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.

ogra 2017-11-02 14:25:46 UTC #4

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…

mborzecki 2017-11-02 14:50:39 UTC #5

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.

chipaca 2017-11-02 15:04:54 UTC #6

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.

chipaca 2017-11-02 15:05:48 UTC #7

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

niemeyer 2017-11-09 18:47:42 UTC #8

@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.