o/snapstate: avoid setting up single reboot when update includes base, kernel and gadget
* o/snapstate: avoid setting up single reboot when update includes base, kernel and gadget
Otherwise there is a circular dependency between base, kernel and gadget, where
the kernel waits for gadget (to handle gadget assets update), gadget waits for
the base, and the base waits for some of the kernel tasks.
Signed-off-by: Maciej Borzecki <email address hidden>
* o/snapstate: procure circular dependency and verify abort untangles the state
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord/state: add helper for aborting unready lanes
A helper for aborting all lanes that aren't ready in a given change. An unready
lane is one that carries tasks which have not reached a final status yet.
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord/state: drop unused lanes field
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord: wait for up to 3 days before automatically aborting a change
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord/state: use AbortUnreadyLanes when pruning
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord: managers test to verify self healing via abort-unready-lanes in prune
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord: leave a comment about the scenario being tested, test tweaks
Signed-off-by: Maciej Borzecki <email address hidden>
overlord/state: add helper for aborting unready lanes
* overlord/state: add helper for aborting unready lanes
A helper for aborting all lanes that aren't ready in a given change. An unready
lane is one that carries tasks which have not reached a final status yet.
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord/state: optimize lane check, test tweaks
Signed-off-by: Maciej Borzecki <email address hidden>
* o/state: more tweaks
Signed-off-by: Maciej Borzecki <email address hidden>
* overlord/state: simplify checks, tweak commets
Signed-off-by: Maciej Borzecki <email address hidden>
interfaces/docker-support: make generic rules not conflict with snap-confine
* interfaces/docker-support: make generic rules not conflict with snap-confine
The rules we inject into the profile to account for allowing devmode snaps to
execute other snaps are in conflict with these, meaning that the docker snap
(and the strictly confined microk8s snap) cannot be installed with devmode
confinement which sometimes needs to be done. So make these generic rules allow
anything except very specifically the transition rules which we inject that
have regular expression wildcards in them to get the policy to compile
properly.
Also adjust the spread test to ensure we are testing that the docker snap can
be installed with devmode, at least to the point where apparmor profiles are
compiled correctly.
Signed-off-by: Ian Johnson <email address hidden>
* interfaces/docker-support: re-word comments for clarity
t/m/interfaces-network-manager: use different channel depending on system (#11422)
* t/m/interfaces-network-manager: use different channel depending on system
Install network-manager from different channels depending on system
under test. Due to tight integration with UC, each UC version requires
a different NM snap.
* using os.query instead of checking $SPREAD_SYSTEM
