Point of the exercise was to make it clear how to build a snap, and make the results consistent. Whatever we do, we should avoid breaking these properties.
Launchpad can only build Ubuntu for now
Best path might be to have a VM image and a LXD container that are equivalent, and allowing Snapcraft to recognize both
Cloud image is not as stable as we’d like for being a build environment
We need a new image that is a VM image, a LXD container image, and a tarball, all with the same content (or very simliar) that can be used by Snapcraft and Launchpad
When snapcraft detects that it is inside a destructable environment (e.g. Travis build) it can set itself up as necessary
snapcraft [–lxd | --multipass]
Snapcraft with needs a registry of names associated with images
Images must be almost exactly the same across lxd and multipass
Ideally the site should keep the cache if it cannot reload
Current reload timeout is 5 minutes
We’ll add a section to the documentation outline with a map of high-profile link names to URLs
After snapcraft docs are out, next step is implementing the importer for MaaS
Snapshoting of documentation for different major versions will work by copying the content to a separate category and adding some kind of e.g. “2.42” text to the topic title, so it doesn’t conflict with the latest version
The store and snapd itself were already improved to return nice error messages when the snap is only available on a different architecture
The find command won’t return snaps that are only available on different architectures, though. This may be the best approach, so snapd won’t suggest snaps that can’t possibly be installed locally.
Please implement 301 Redirects on the old docs.snapcraft.io document pages to their respective new locations. Each page will need to be routed to it’s counterpart, not to a single generic front-page. This will capture the SEO juice of the old URLs and forward anyone to the correct page when clicking out of date links.
For example, the old “interfaces” page needs to redirect to the new “interfaces” page, not to the front page of the new docs site!
New snaps should follow traditional processes for other images shipped by Ubuntu
Updated whenever there are security issues, as usual
core will still be maintainable in the near future for compatibility purposes, and until a transparent migration from core to core16+snapd is possible.
snapd team maintains core, foundations team maintains core16 and core18
Retention policy for general images in general is 3 days
New core16 and core18 snaps ship every time a package in the manifest is updated
As usual, new snaps first go to edge channels first, and flow up from there
Test suite needs to make sure core devices can still boot with updated core snaps
Process:
Upload to edge automatically
Several tests are run automatically, from different teams
Tests pass, move to candidate
Nobody complains, 48h later it goes into stable
If end of timeframe falls on weekend, it’s expanded to fit whole Monday
This flow doesn’t mention the beta channel at all, which has historically been tested by CE on Commercial/Reference Devices. Would this still be the expectation with this new flow? Our fully automated infrastructure looks for new snaps in the beta channel for the vast majority of snaps that are shipping on commercial devices, and it would be quite disruptive to special case the Core snap to test in Edge rather than Beta.
The tests mentioned above run by CE do this (and quite a bit more of course) on both Commercial Devices as well as all reference devices (rpi2, rpi3, CM3, Dragonboard, NUC, etc)
People want RPMs of snapd for other distributions (non-Fedora)
We’ll put some additional RPM distributions in the functional test suite
Apparently some applications are always autostarted with no way to disable. Unknown to the team… reproducer is needed.
Some publishers are looking for better handling of links (irc://, etc)
Support for document portal is desired for some snaps. In theory that’s already done as far as snapd is concerned. Need to confirm what else needs updating for it to work.
If implemented as discussed today, the snap that goes into the edge channel will be unstable and untested. After tests pass, which should include the tests from your team, the snap is promoted to candidate. A promotion to candidate implies any systems following beta will also pick it up, per usual rules for channels. These semantics are in place precisely so that consumers can follow any of the channels, and they are guaranteed to observe the snap in candidate if beta is closed, or stable if both beta and candidate is closed.
Note that the tests that run while moving from edge to candidate must all be automated. We cannot have any manual steps between the edge stage and the candidate stage because these updates will almost always be about CVEs, which need to hit stable very timely. After it hits candidate, there will be a pre-defined amount of time for manual and external tests that might block the stable release if reported and depending on severity.
Also worth noting that these updates won’t include any snapd changes or any other non-security-critical fixes. The snapd changes will be published in the snapd snap itself, in that new world.
How does one get involved? More specifically I would be interested in some working on updating the Go plugin and fixing some issues I’ve had with Rust snaps.
Thanks for your interest. The best way to start the conversation might be to create a topic here in the forum in the #snapcraft category, detailing what you’d like to get done. Then someone in the team (probably @sergiusens or @kyrofa) will reply with suggestions for how to achieve it, and how to submit it.
If you have any trouble doing that, please ping me again.
Reorganize help so it’s shorter, fitting in a 25 lines terminal
Group commands by functionality
Automate creation, and make sure new commands have a group
snap help --all lists everything with summaries, grouped in the same categories
Proposal for the text of snap -h/–help, snap help, and snap on its own:
The snap command lets you install, configure, refresh and remove snaps.
Snaps are packages that work across many different Linux distributions,
enabling secure delivery and operation of the latest apps and utilities.
Usage: snap <command> [<options>...]
Basics: find, info, install, list, remove
…more: refresh, revert, switch, disable, enable
History: changes, tasks, abort, watch
Daemons: services, start, stop, restart, logs
Commands: alias, aliases, unalias, prefer
Configuration: get, set, wait
Account: login, logout, whoami
Permissions: interfaces, interface, connect, disconnect
Development: run, pack, try, ack, known, download
For more information about a command, run 'snap help <command>'.
For a short summary of all commands, run 'snap help --all'.
Server side has most of the complexity, and is mostly done
Client side is not finished, but is very simple in comparison
We already accept both the shorthand notation and the extended notation in snap.yaml
Must make sure snapcraft already recognizes the field with both formats (cc @sergiusens)
Do we send to the store on refreshes already?
Must block updates
When the write epoch changes locally, a refresh needs to be scheduled shortly thereafter
Snapshots need to block restores to a revision with an incompatible epoch, much like snapd must block the install of a snap that cannot read the data
Snapshots already store the epoch
Documentation must get written. Here in the forum we have very good coverage of the low-level details, and some coverage of high-level ones.
User data is not part of this picture at the moment, because it requires users to actually run applications for the data to be updated, and there’s no registry of all the users that have ever run the application
We may add snapctl epoch for querying purposes
In the future we may also support dynamically setting the write epoch via snapctl set-epoch
As soon as the basic functionality of snapshots are in master, we’ll start working on the client side of epochs
Snapshots will be considered actually done when a refresh or a remove does a snapshot automatically
We need the new kernel name and schema that allows upgrade to be independent for diverging platforms
A snap built can only be uploaded once to the store
That means a single kernel that works on multiple devices needs to either be built twice, even if the bits are effectively the same
Proposal is to use “kernel” as the snap name, and then individual tracks “18-pi2”, “18-pi3”, “18-cm3”, etc
Same for the gadget: a “pi” gadget, with tracks named “18-pi3”, etc.
The advantage of this schema is that one build may be published in multiple platforms, but when necessary they may also become independent builds
This schema may be used by third-parties as well
The model will mention something like “kernel: kernel=18-pi3” to lock down the track name for this particular platform
In those cases snapd won’t allow changing the track, as it would invalidate the model
That takes away some freedom from the track functionality, but that sounds okay for this specific context, since we don’t expect more variance than what’s already allowed by the risk levels (edge, beta, etc) plus branches, which all work within a single track
The “snap info” command needs to be modified so that when the model has a locked track, only that specific track is shown; that prevents people from seeing tracks for completely unrelated devices, and also is prevents encouraging switching tracks and that’ll error out on that device
Ubuntu Core 18 status and next steps
Dragonboard still crashing
Pi 2 and 3 have network issues with console-conf
We need the “classic” snap for core18 still
How do we get different environments from same snap
classic→Classic environment for current boot base
classic.16→Ubuntu 16.04
classic.18→Ubuntu 18.04
classic.fedora28, etc
It would be great to have that working inside classic systems as well, in addition to core devices
The “classic-support” interface and the driving shell script inside the snap need to be reviewed and modernized
Hide bases by default from snap list
Bases need to be removed when they become unnecessary
note that these most likely come from the fact that the gadget in stable uses an extremely outdated boot firmware (one old enough to not have full support for all power management, thermal control and other bits that will influence the operation of peripherials).
There have been multiple approaches to make snapd allow gadget payload updates (and there are multiple forum posts about it), the last one is here i think:
this has never been implemented, with the result that the stable pi gadgets all stayed on a pre-release firmware (with the exeception of the cm3 where we had the opportunity to use a newer firmware from the beginnning, since the initial image was created a lot later than the other two), there are no networking (or other hardware) issues with the edge images .
the same goes for graphics support on all pi devices, the gadget firmware in stable pre-dates many fixes and configuration options for the pi that are all fixed in the edge gadget which could never be released due to the above missing feature.
EDIT: whoops, sorry, i guess for core18 michael actually used a newly created gadget with a newer firmware when doing his test images, in that case the above would indeed not apply (still an issue in core16 though)
Will there be any alternative on core devices to find out which revision of the rootfs snap you are running beyond snap list (this can be pretty essential info at times) ? Or is the plan to only hide the additionally installed bases there ?
Fundamentally, allows going from one model assertion to another
In some cases this might be a new revision of the assertion, which means it’s automatically updated
In other cases, it would be a manual (or driven externally to snapd) action shifting from one model assertion to a different one
We need to research how to integrate the remodeling procedure into the serial vault, so that the device can become a new model as soon as it requests a serial for itself.
The goal is allowing changing of all details of the model: base filesystem snap, kernel, gadget, store, required snaps, etc.
Internally in snapd, we hope to implement all those changes using the same code path. Among other things, that means being able to shift back to a previous model.
Change of model needs to be approved in the model itself, with language to be defined.
Change should be approved in both directions. That is, the target model should be able to restrict which models it can be transitioned from.
Wildcards allows accepting all transitions (or perhaps not specifying anything allows all transitions, TBD).
Restrictions might be specified per brand, maybe?
There might be use cases to allow the gadget to start the remodeling via snapctl.
Ideally serial would be obtained in the beginning of the transition so it can use it to communicate, but there’s a chicken and egg problem, because downloading the new gadget might require a conversation with the right brand store, and the new gadget might be required to acquire the new serial, and the new serial is required to talk to the right brand store. Loop must be broken somewhere.
We might start with a smaller use case where only some fields in the model are allowed to transition. Changing only the store, and perhaps installing non-core required snaps (not kernel, gadget, core, base) might be easier.
There are legacy cases which use a store but are using the generic model. This is an unsupported use case, and needs to be ported to a normal scenario where a model is involved and detailing the store.
