If an installation fails because package not available, snap is suggested
Not yet integrated into the search hook
Display the first N (5… 10?) entries from find results, so it doesn’t get too busy
Store is already ordering results based on relevance
Might be presented along the lines of:
$ apt search ...
<apt results>
<empty line>
Related snaps matching "aws-cli":
* aws-cli - Universal Command Line Interface for Amazon Web Services
See 'snap info <snap name>' for available versions.
Improve “snap info” output with another field at the end:
Hook named “check-health” (or similar) is called by snapd to check for health
Hook needs to be idempotent so snapd can call it at any time
Hook might be called every 5 minutes to begin with, maybe? We can always increase later (but we can’t easily reduce it, without risking breaking applications that expect having more time for it)
Have special status “unknown” if the snap hasn’t bothered to define it
If the health-check hook is called and it doesn’t update the status, it’s set to “unknown”
Goal is to make cups installed as snap to be available for applications to print on it
The “control” in cups-control is there because snaps can run as root, and that gives connected snaps full administrative capabilities via the cups socket
We might have a “cups” interface that bind-mounts /etc/cups/client.conf when connected
Classic applications would not see that file, though, and wouldn’t be able to print into the snapped cups
The cups snap can also try to allocate port 631 by default anyway, and make itself available for printing for the whole system
Another more complex alternative:
Cups is able to chain two cups installation together; easiest is probably to allow the cups snap to cups-control the system cups, and make itself available for printing automatically
Apparently some of that already works today with the snap, but it might be automated further to make the process less painful for users
Unlike debs and rpms, publishers push the built snap, so there’s no strict source package
That said, snapcraft provides a manifest of how it built the snap, and packs it inside the snap, so that may be used for informational purposes
Open source snaps may be rebuilt using the snapcraft.yaml and manifest that was generated
Snaps published by the “canonical” account may use branches to publish hotfixes
Third-party publishers need to publish their own hotfixes, and in some cases contracts may exists so that Canonical can publish hotfixes as well.
There’s a line of responsibility that should not be crossed without an agreement in place. Canonical shall only publish a modified snap into a channel of a third-party snap when there’s a contract in place for that.
Alternatively, snaps may be locally installed using --dangerous, but that may behave differently with connections/etc since the store information (snap-declaration) will be missing.
Alternatively², snaps may be published under a different name altogether.
Change snap-confine to repeat the same process for non-user mount namespaces, effectively saving the snap namespace and then the per-user mount namespace on top of that
Before that’s all in, there should be a way to convey experimental flags into snap-confine
Relatively simple change to snap-discard-ns and snap-update-ns to glob uids in the directory with mount namespaces (/run/snapd/ns)
After that we can enable the content interface to use user data!
Realistic timeframe: 1 week to land the C code, and 1 more week for the Go part
We need to get agreement on the experimental flag first
Root namespace for classic snaps
Allow classic snaps to use:
Layouts
Parallel instances
Some otherwise problematic interface
Mounts would stop propagating, which is a breaking change
Perhaps do the per-instance unsharing and stop propagation of events in /snap, but still consume them; that’d keep parallel instances happy and things working as usual otherwise
That’s related but not entirely to that other mode where the snap is unconfined but in a mount setup that matches that of a strict snap; the snap would need to opt-in and pass review per classic rules.
Possibly specific to user, model, device, brand, etc
Installation of the whole snap might also be restricted, and in that case the blob shouldn’t be made available
We need a better name for “entitlements” that is shorter and simpler
Entitlements might have two kinds:
Store conveys to snap via assertion everything that might work offline
Sometimes a token will be required for speaking to a third party and proving right of access
In theory we might also convey the first kind via an assertion, but that’d mean refreshing the whole assertion which is more expensive than refreshing a single token
Assertion might be refreshed when a new question is asked, perhaps with a threshold for caching up to N minutes so we’re not trashing the server
Entitlements (not the assertion) must have an “until” field so it’s not valid past that point, must be refreshed before that
Should we design so that we have different commands for “give me” vs. “do I have it”?
snapctl use hats=10
snapctl used hats?
snapctl use autopilot # Binary, same as =1
snapctl used autopilot?
These are not the real commands… these need to be defined still
Next steps
Get some actual design going
Get some code working in snapd for experimentation
Trademark violations - upstreams with trademarks requesting their mark not to be used
Renaming a good-name-someone to simply good-name
Upstream project name has changed
To allow automated refreshes over renames, we might leverage the alias feature so that the original commands remain working
The new warnings feature allows conveying to the administrator that the rename has happened
To support reverts, we’ll need to mount the new name over the old name so that the snap sees itself over its original location. We might make this more general by always forcing the snap to be mounted using the name in the snap.yaml file. That feature would reuse the “overname” logic implemented for parallel installs.
Snapshots also need to do something about renames, so that they can be associated with the correct snap
The store might get a lookaside table that has a list of renamed snaps, so it can still accept snaps published with the old name. This would only work for as long as the entry in that table exists, and if another snap takes over the old name the lookaside table is cleaned and the old name is associated with the proper snap.
For daemons being kept alive across refreshed, they are restarted for that one refresh.
We might start by doing just the easiest parts of the problem, requesting a manual refresh, and then tackling more of the problem later.
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