Porting hardware testing tool to snappy Ubuntu core

[Sergio Schvezov]

On Tue, Jun 02, 2015 at 02:52:42PM +0200, Zygmunt Krynicki wrote:
> Hi
> 
> I'm working on porting a hardware testing tool to snappy. I've done
> some research by looking at the available documentation on the wiki
> as well as by experimenting with a beagle bone black, running
> 2015-04-23 image.
> 
> On classic distributions we rely on a number of third party tools
> and relatively unconstrained access to the system. In snappy we will
> likely have issues related to not having certain tools in the base
> image and by the enforced container / seccomp / apparmor
> restrictions.
> 
> The application is composed of a large number of executables with
> various dependencies (on language runtimes and external commands).
> Many of those run as root to perform some operation.
> 
> I did a quick analysis to see what kind of issues we currently face.
> I would love to see how to proceed on each of those, given your
> plans for snappy and best gut feeling on what to.
> 
> storage:
> - no udisks command line tools
> - no udisks service

This is fine, it could be provided as some sort of framework if you
wish.

> audio:
> - no pulseaudio
> - no alsa tools

This is fine as well.

> device enumeration:
> - constrained udev (doesn't know about any device)
> - no access to /sys
> - no access to /dev

This is per design.

> display:
> - no X (e.g. no way to enumerate supported resolutions, screen
> rotations, monitors, no way to do any changes)
> - no mir (ditt, though this is expected at this stage)

Per design. mir will be a framework eventually (look at mterry's

deb2snap example for mir)
> time:
>  - no access to /sys (for rtc)

Debatable, but not entirely blocked due to being able to right your own
apparmor rules.

> cpu:
>  - no access to /sys
>  - (odd) /proc is fully available, will that change later?


I leave this to jdstrand.
> software:
>  - (odd) dpkg is still available, will that change later?

Pending removal.

>  - no api (now) for snappy (should we parse output of "snappy list"?)

There's a go API, there's going to be a restful interface.

> power management:
>  - no access to /sys
>  - should we use systemd APIs?

No comment on my side.

> In exploring this I considered making the whole snappy application
> unconstrained, making it a framework (and letting individual tests
> be snappy applications that use it).

This is a possibility. Or just unconstrain it enough so your tests can
run.

> One thing that does stand out as problematic, apart from security
> constraints, is the relative emptiness of the core snappy image.

We are planning on removing more.

> I think it's unreasonable for us to ship udisks so that we can have
> some simple disk enumeration and storage tests. On the other hand,
> udisks is a well-established "plumbing layer" software that we rely
> on and would not like to have to re-write everything again so that
> we can work on Snappy. I'm sure there's a better way to do it.

Look at deb2snap maybe it solves your problem.

> Lastly there's the question of language runtimes. I talked to ogra
> on IRC earlier today and he confirmed that all language runtimes
> will be removed down the line. Should we start exploring making each
> runtime that we use and rely on a framework?

snapcraft should be pluggable and take care of language runtimes, but
yes, python3 is going away eventually (as soon as we transition away
from the python dependant components).

Cheers
Sergio