Planning OTA work for Jasmine Sprint 3

Hey everyone, but mostly @Wojciech_Zmuda and @agherzan

I was trying to come up with the theme for the upcoming sprint with the relation of the OTA work. I would like to see the following happen:

  1. Get the transactional OS bits off the ground - to start producing some images, to start writing our state handling logic and to brainstorm testing around that

  2. Continue SystemOTA development to be able to pull files and drop them in the file system. This will involve very basic server-side tooling, the request/response formats and will start to unlock the vast security topic here: signatures, ssl certs, pinning etc. I would also like to improve the CI a little, to have test coverage displayed in GitLab

  3. Look at bringing meta-golang home, so that we can start exploring packaging sysota snapshots into our linux images.

I would like to know your opinions and then have a high-bandwidth call to do task planning.

My proposed focus for Sprint 3 is your number 1 in the list above. It is the natural next step after the partition table being defined and in place. That means switching the root filesystem to read-only (either by configuration or filesystem type) and designing a state structure for the writable bits. Let’s fix a call early next week to decide on the areas of investigation on this topic.

The second element I’d like to be at least touched during this Sprint is rauc integration. It is somehow dependent on the above (due to read-only rootfs need). However, we can still invest some time into bringing the related layers, understanding the tool(s) and process(es) and maybe even giving it a spin using the built-in yocto read-only switch (volatile setup).

1 Like

I think @Wojciech_Zmuda has filed some tasks related to that. Let’s review them and see if they look all right to everyone. This is the list of OTA issues that are in the system now: Issues · OSTC · GitLab - let’s pick a list by assigning the iteration number to those that we feel are going to be picked up this cycle.

We had a call about this last evening and this is my summary:

  • we move towards on all fronts, trying to meet in the middle
  • we push the read-only rootfs work, exploring initrd and configuration (more below)
  • we push the bitbake side, to get sysotad packaged, to get initrd bits aligned
  • we push the ota service side to integrate with RAUC bootloader code

One note about configuration. You may recall our previous discussions about “state operators”, the entity responsible for making specific places mutable or persistent, on top of default read-only nature of our rootfs. We discussed this a little bit more and decided to have per-package information that is aggregated at build time into a single configuration file that is then loaded and processed in initrd.

We also said we will start with an limited implementation, allowing packages express at most that a given file or directory graduates from being immutable to being mutable and ephemeral, that is lost on each reboot.

We will grow the set of features, the tooling around that and overrides and patches to specific bitbake recipes, to reach a state where a read-only system boots and has basic functionality: ssh, timezone, hostname can be set and nothing crashes on read-only /etc files.

One consequence of the idea that we provide per-package yaml configuration files that are then aggregated or compiled into one control file, is that we could write our initrd program in something other than Go, for extra compact representation. This is not guaranteed yet though.

One other important remark that we’ve re-discovered is that while we have A and B slots for system image, we also want to have A and B directories on the sys-data partition. This will allow perfect rollback, where all of the state is reverted. The only exception is that sysotad itself will store additional state outside of the A/B model, to understand that a rollback did occur.