It’s going to be a pretty informal discussion intended to tell the story of Ubuntu Core 20, to address some of people’s concerns around Ubuntu Core and snaps in general, and to clarify anything that wasn’t clear from the release. I’m going to work FAQs from webinars and on social media into the discussion and it would be great to include questions from here too.
If you have any questions you would like answered in the stream, post them below and I’ll try and work them into our discussion. This our first time trying something like this so bear with us. But if we miss anything we’ve planned a 10 minute segment at the end to answer questions live from the chat.
Glad to read from you. We have met in person a year ago at the Embedded World in Nürnberg.
Some questions for the upcoming live stream:
With UC18 I was able to create a custom image with locally built snaps (not registered in the store), is this approach no longer supported with UC20?
When building a device from a selection of snaps, It’s of course possible to define a custom image with all snaps preloaded. Would it also be a valid approach to initially just install the default UC20 image from Cannonical to the device and add all snaps via SSH or Snapd REST API?
How the backup an restore the snaps runtime configuration data, or how to replace a faulty device?
How to remotely change the configuration from snaps. For example SNAP_USER_DATA, via SSH or Snapd REST API. Generally, is this not handled on UC side, but is the responsibility of the users (not enduser)? Maybe it’s advised to expose the configuration to /v2/snaps/[name]/conf ?
The last two questions basically lead to the general topic of fleet management. Is there a turn-key solution available?
The roadmap of Ubuntu Core mentions real-time capability for future releases. Are there resources available on this topic, or even development kernel snaps?
As I understand there are no desktop GUI session possible with UC20? I think UC would be a great platform for Kiosk applications. E.g. one single user facing electron app? Would this be possible, maybe in upcoming releases?
For using cloud-init specifically with UC20, we have changed the way that cloud-init works with UC20, specifically cloud-init is only usable under certain conditions, see this table for a full picture of how/when you can use cloud-init. We are working on a doc page about using cloud-init with UC20 to better explain this but it’s not ready quite yet
The prepare-device hook is not usable for this, but the ubuntu-data partition mentioned in the gadget.yaml is automatically expanded to use the rest of the disk if it is the last partition/structure in the gadget.yaml.
There are a few ways to handle configuration. You can integrate it into snapd’s existing configuration system where a user runs snap get or snap set outside of the snap from a SSH session, etc. that runs unconfined, or this same system can be used from inside a snap to manage that particular snaps configuration with snapctl set and snapctl get, etc. And then finally any snap using the snapd-control can use the snapd REST API /v2/snaps/[name]/conf endpoint as you found. This REST endpoint is only exposed locally on a single device, so if you wanted to do remote management of configuration like this you would need to implement a device management agent which talks to the cloud of your choosing and proxies requests to the locally running instance of snapd to change the configuration. There’s an example of this sort of interaction available at https://github.com/CanonicalLtd/iot-agent.
The other ways to manage configuration are to place files in $SNAP_DATA or $SNAP_USER_DATA, etc. but then this configuration is only modifiable by that snap, and cannot be managed by a device management agent unless the snap also exposes a content interface for those directories. Some snaps such as the edgexfoundry ecosystem edgex-app-service-configurable do this, where the config files live in $SNAP_DATA, but this is exposed by a content interface for another snap to connect to and modify as necessary.
Regarding your question during the livestream about backing up this configuration, we expose snapshots via snap save and snap restore which stores both the data in the snap config system (i.e. snap set) and the data stored in writable areas of the snap ($SNAP_DATA and $SNAP_USER_DATA, etc.) into a snapshot that can be restored later. This snapshot system can also be driven over the snapd REST API by a device management agent as well.
Hopefully this helps answer some of your questions. Let us know if there’s more information you’d like to know about UC20 or snaps in general.