Daily 2018-07-13

2 minute read Published:

Friday, 16of July 2018

This is a draft of a new blog post that doubles as a twitter log. The idea is simple. Tweet a thread a day. Post it as a blog item for prosperity^Hvanity.

So let’s rewind to Friday the 13th of July. It’s the last day of the week and I promised myself to end the week with a good outlook on core18 interface support.

The general idea is that as we move away from the core snap providing slots like network or home we need to hold them somewhere else. That place is the new snapd snap.

One of the points raised by code review was that we wish to do a more complex transformation than I initially assumed. We needed to apply different transformations in the state than in the API.

The on-disk state needs to refer to core snap to support rollback. The memory needs to refer to snapd snap because that’s the real host of implicit interfaces. The new thing is that the API layer needs to refer to the system snap as that concept was showing up in other places.

This, while making the mapper more complex, actually solved the issue having a growing number of special cases in client code. The client could just special case one snap, namely system.

Note that system can be omitted so for example the network slot commonly written down as :network is really system:network.

As I did this I realized we have code that special cases system already, under the term nickname. The core snap has a nickname system and the system nickname can be resolved back to core. This nickname idea was used in both client and server side code.

This was bad because only the server would know how to resolve the system nickname (either to snapd or to core). I had to change that.

I decided to merge the nickname concept with my interface mapper and, at the same time, simplify the interface mapper (which could rename plugs and slots at will) to just a snap mapper (which can just rename snaps).

This actually worked very well. The nickname system is entirely server side (client doesn’t know anything about it now). The code is much shorter than before and handles the three-way case correctly.

I pushed all of that to https://github.com/snapcore/snapd/pull/5491 and went to sleep. On the following day I worked a little on the train to provide the one final patch that makes core18 interfaces possible: https://github.com/zyga/snapd/commit/c69daaba9adf2e1d37a439eec248aeec3949c306

I let @mvo5 and @pedronis know about this and wrapped up for the week.

comments powered by Disqus