On Tue, Aug 21, 2018 at 11:41:18AM -0700, Steve Langasek wrote:
> Hi Stéphane,
Hi Steve,
> On Mon, Aug 20, 2018 at 05:13:11PM -0400, Stéphane Graber wrote:
>
> <snip>
>
> > The package in its preinst will attempt to contact the snap store,
> > holding package upgrade until it's reachable, then ask the user about
> > what track they'd like to use, followed by installing the LXD snap,
> > waiting for it to be online and automatically run the migration tool.
> >
> > Should any error happen, the deb content will remain on disk (as all
> > this is done in preinst). We can then provide individual instructions
> > for failed migrations and update lxd.migrate to account for any cases
> > that it couldn't handled.
>
> <snip>
>
> > The current plan is to have Ubuntu LTS releases default to installing
> > from the most recent LTS track (currently "3.0") while non-LTS Ubuntu
> > releases should default to installing from the "latest" track.
>
> > The debconf prompt will always be shown, so this will only affect the
> > default selection.
>
> It is impossible to enforce that debconf prompts are shown in all cases.
> Unattended-upgrades are a thing. Manually setting
> DEBIAN_FRONTEND=noninteractive is a thing. DEBIAN_PRIORITY=critical is a
> thing (and while it's probably reasonable for the "cannot talk to the store"
> error prompt to be shown at critical priority, I think track selection
> fits the definition of a high-priority debconf prompt, not critical).
Fair enough, moved all prompts to "high" except for the unreachable
store one which remains "critical".
> This is a general rule anyway, but please be sure that the package behavior
> is sane when the debconf prompts are not shown.
The preinst both attempts to show debconf prompts AND prints relevant
messages to the terminal.
> - What should the behavior be if the store cannot be reached and the prompt
> cannot be shown? Should the preinst loop indefinitely (causing
> unattended-upgrades to hold the apt lock forever until the admin
> intervenes), or should the preinst abort (causing an apt transaction
> failure)?
My current logic is to trigger the debconf prompt and if unusccesful to
print "Unable to contact the store, trying again in 1 minute" to the
terminal and wait a minute before trying again.
> - If it should abort, you may find /usr/sbin/update-secureboot-policy in
> shim-signed to be useful prior art. ("$seen_key")
> - If it should loop forever, please ensure the maintainer script outputs
> sufficient information to stdout/stderr for the apparent hang to be
> debuggable from just the apt log. (But maybe don't generate output for
> every loop iteration, since making /var/log ENOSPC is not the ideal way
> for the admin to discover the problem either.)
Good point, I'll change the logic to be a bit less aggressive logging wise.
I think I'll actually go with a hybrid of the two options:
- If possible, show the debconf critical prompt
- If that doesn't work, print to the terminal that we'll retry every
minute for the next 30 minutes.
- Log something again after 10 and 20 minutes
- Abort at 30
> > A branch of the stable channel of those tracks will be created and
> > closed per policy on seeded snaps (allowing to push emergency snaps to
> > those users bypassing the upstream).
>
> Excellent!
I actually had a question about that part, the wiki says to create an
ubuntu-18.10 branch and use that during snap installation.
But then what's responsible for switching this to a ubuntu-19.04 branch
during the next upgrade?
Since the same version of the snap will be pushed to all Ubuntu series,
wouldn't it make more sense to have it just be "ubuntu", saving us the
trouble of having to figure out what to do on Ubuntu release upgrades
and reflecting the fact that the snap is the same for all series.
Stéphane
