Designing the storage API for the installer

Hi,

I’ve just created a pull request for subiquity which hopefully adds enough of an API for the new desktop installer to be able to use the guided “just install ubuntu to this disk” option which is probably all the very first version needs.

As I work on this, thoughts obviously turn to what API the new desktop installer needs for storage. What the server installer does today is make one API call that returns the existing config (as curtin storage config), then everything happens entirely client side until the client sends the final config back to the server. This is kind of OK when there is only one client (and it allowed me to implement the client server split more easily) but when there are two clients (server and desktop installers) it might make more sense to move most things into the server, maybe creating a sort of RESTish API for storage config manipulation. This would avoid reimplementation of many details and make sure the two installers are consistent with each other. OTOH, it would also be quite a lot of work to get done.

Another argument for doing things more in the server is so that the server can listen to udev events and inform the client when, for example, a USB stick is plugged in.

Anyway, I’d like to know what the new desktop installer developers think!

2 Likes