Experimental offline mode fails with network present
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snapcraft |
New
|
Undecided
|
Unassigned |
Bug Description
The experimental offline mode in snapcraft does not work as intended, and does not have a graceful failover.
How to reproduce:
Ubuntu 18.04 system (and also in some cases 20.04)
Run snapcraft --offline (with lxd or multipass) on any snapcraft.yaml
The run will fail with:
Sorry, an error occurred in Snapcraft:
'NoneType' object is not subscriptable
We would appreciate it if you anonymously reported this issue.
Complete trace:
Traceback (most recent call last):
File "/snap/
sys.exit(run())
File "/snap/
return self.main(*args, **kwargs)
File "/snap/
rv = self.invoke(ctx)
File "/snap/
super(
File "/snap/
return ctx.invoke(
File "/snap/
return __callback(*args, **kwargs)
File "/snap/
return f(get_current_
File "/snap/
snap_
File "/snap/
return ctx.invoke(
File "/snap/
return __callback(*args, **kwargs)
File "/snap/
_execute(
File "/snap/
with build_provider_
File "/snap/
self.create()
File "/snap/
self.
File "/snap/
self.
File "/snap/
super(
File "/snap/
snap_
File "/snap/
snap.
File "/snap/
host_
File "/snap/
if self.has_
File "/snap/
return not self.get_
TypeError: 'NoneType' object is not subscriptable
Expected behavior:
1. If snapcraft --offline is run and there is network and NO cached assets exist, it should inform the user that it needs to pull the assets from the network the first time.
2. If snapcraft -offline is run and there is network and cached assets, it should run as though there is no network; and there should be no errors.
3. If snapcraft --offline is run and there is no network and no cached assets, it should inform the user that it cannot complete the task as there are no available assets that can be retrieved.
4. If snapcraft --offline is run and there is no network and but there are cached assets, it should complete normally.
Also, if snapcraft is run without offline mode (not specified) and there is no network, it should check for network status first before trying to launch the container, as the container startup will time out (unspecified) but this behavior cannot be distinguished from: a) slow network b) slow vm/container behavior where it can take a long time (minutes) for the vm/container to start.