The road to core18

snapd
6

Thanks, I edited the above and removed the suggestion to use series=18 for this.

7

notice that there might be a way to not need the add base: core18 to the preexisting model assertions by revving them, it might also be a way to express the upgrade. ATM we don’t update model assertion of preexisting devices but we do need to allow for it in some controlled way.

8

We just discussed the model assertion issue (briefly) during the standup and the agreement was to have a new model assertion with a different name for “Ubuntu Core 18” for now. This model assertions will have different names from the existing:

  • pc-amd64
  • pc-i386
  • pi2
  • pi3
  • cm3
  • dragonboard

There are some options, the easiest to just append a -18 to each. However @niemeyer suggested to take the opportunity to cleanup the names and e.g. use something nicer for the pc-* names (as not all Ubuntu Core devices that run i386 code are PCs).

9

perhaps also reflect the architecture in the the names of the arm ones … (pi3-armhf-18, dragonboard-arm64-18 etc etc …)

10

In an ideal world, I think that ‘snapd’ as a ‘regular snap’ should be fine, but I’m concerned with how this will intersect with our sandboxing because snapd and snap cannot fail since if they do, we won’t be able to apply bug fixes.

Right off the bat, the ‘snap’ command could cause trouble since seccomp can only get more strict. Furthermore, if other interfaces are plugged then the device cgroup may come into effect. AppArmor should be ok with appropriate policy, but we’ve already seen issues where simply the act of not running under the ‘unconfined’ label causes changes in behavior (fd delegation, the recent unlink/linkat bug with Qt 5.10). We could specify ‘confinement: classic’ but that isn’t available on Ubuntu Core and even if we adjusted for that, it won’t solve the potential ‘not unconfined’ issue, especially when considering partial and full confinements and the myriad of kernels out there.

As such, at least for core18, I suggest the magic approach (or an equivalent where snapd and snap are run outside of any sandboxing/security labeling) for now. When I heard the idea of splitting out ‘snapd’ from ‘core’, I always figured we’d introduce a new snap type, ‘snapd’ and then we can do whatever is needed based on that.

1 Like
11

Thanks Jamie! I updated the section about snapd as a snap based on your feedback. We also discussed this today after the standup and reached the conclusion that the snapd snap will need some (simple) helper that gives us the systemd units it needs and then we will add a core18 snapd-startup.service unit that will add these units and try to start them. if starting of snapd fails it this snapd-startup.service unit will retry with the previous version(s) of snapd and fallback to the seeded snapd snap if needed. The key here is that we want a similar level of robustness as we have for the snap_mode=try on boot.

12

Strawman for the names:

  • core-amd64-18
  • core-i386-18
  • core-pi2-18
  • core-pi3-18
  • core-cm3-18
  • core-dragonboard-18

This leaves a clear path towards equivalent classic images on all these cases.

1 Like
13

Does systemd remain in the core(base) snap after the split?

14

Yes, although it’s not a general requirement for base snaps, some bases and specifically the ones used for Ubuntu Core will have systemd.

15

Yesterday and today I was working with mvo on an idea how we could handle implicit interfaces in core18 world. As you may know, today snapd adds all the interfaces that declare themselves as implicit to the core snap (or the ubuntu-core) if present. In fact, today the interfaces are added to any snap with the type “os”.

This poses issues in core18 world where there can be a core boot snap, a core18 base snap along with a fedora29 base snap. If an IRC client snap has a network plug, what would it be connected to?

The proposed idea is to create a new virtual snap that would hold all implicit slots. Since we already use the name system for virtual configuration of the core snap I decided to run with that name.

Some hacking and experiments later I have a branch at https://github.com/zyga/snapd/tree/rfc/virtual-system-snap which essentially works okay. Implicit interfaces show up on the system snap. Connections, auto-connections and disconnection work just fine. I even used a trick where the connection state is mapped back and forth so that the on-disk state only talks about the core snap, while in-memory state shows system. This is making the patch harmless to rollbacks.

What is missing? Unit tests on the interface manager need tweaks because they assume interfaces show up on core and that implicit interfaces are added to any type: os snap.

We also need new tests and other obviously missing aspects. This branch is an RFC for discussion.

1 Like
16

As a quick end-of-week update: creating a core18 image that boots/seeds and runs snapd via the snapd snap is almost working. The following PRs need to get merged:

When those are in ubuntu-image should be able to create an image that is able to boot and seed the snapd/core18/pc/pc-kernel snaps and that can install/run basic snaps. It will be an important step because it means we can start creating spread based integration tests.

Note that there is still a lot of work ahead, interfaces are not working yet (see @zyga-snapd post above about the plan here) and configuration is also not there yet. The general robustness is also lacking. With these caveats it will still be a nice milestone when we can run our first spread test :slight_smile:

2 Likes
17

Do you have an ETA for core18?

18

I think the rough ETA is 18.10 but it will be likely available sooner than that.

3 Likes
19

I updated the post with the latest status and agreements. Please let me know if anything is unclear here.

1 Like
20

Any idea when this new track will become available?

21

Is this accurate? AFAIK the interface work is (should be?) complete now.

22

Hello, just wondered if there was any additional info / ETA’s on this?

1 Like
23

@mvo:
Hey @vpetersson,

we have no plans to make this an automatic operation. It will have to be triggered via an explicit command (either CLI or REST API).

We will keep the The road to core18 9 updated with the progress.

Hey guys (especially @mvo) wondering what the CLI command is to upgrade from core 16 to 18? We tried doing this by specifying a new channel and snap refreshing, and it would have locked us out if we’d done this on a field unit!

24

What’s the current status of this @mvo ? Thanks!

25

This script is now deprecated, can we update the description here with how it now works? I see the PR that we changed that was in https://github.com/snapcore/snapd/pull/5557