Deploying in an LXD container results in an inability to install kube-* snaps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Kubernetes Control Plane Charm |
Triaged
|
High
|
Unassigned | ||
Kubernetes Worker Charm |
Triaged
|
High
|
Unassigned | ||
snapd |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Deploying kubernetes-master in a privileged container results in the kube-* snaps not being able to be installed:
sudo snap install kube-apiserver --channel=
error: cannot perform the following tasks:
- Run configure hook of "kube-apiserver" snap if present (run hook "configure": cannot perform operation: mount --bind /snap/core18/
This appears to be due to a change that was recently released [1] which, in a privileged container, causes the container, which has a newer effective snap-confine profile than the host. Since the container does not have confinement, it reverts to using the hosts snap-confine profile from an older version of snapd (2.47.1) which does not contain the permissions to allow mounting /etc/apparmor inside the snap.
Upgrading the version of snapd on the host to 2.48+18.04 results in again being able to install the snaps in the container.
[1] https:/
For @Canonical, entire discussion can be found at: https:/
Changed in charm-kubernetes-master: | |
status: | Invalid → Confirmed |
tags: | added: sts |
Changed in charm-kubernetes-master: | |
assignee: | nobody → Kevin W Monroe (kwmonroe) |
Changed in charm-kubernetes-worker: | |
assignee: | nobody → Kevin W Monroe (kwmonroe) |
Changed in charm-kubernetes-master: | |
milestone: | none → 1.22 |
Changed in charm-kubernetes-worker: | |
milestone: | none → 1.22 |
Changed in charm-kubernetes-master: | |
status: | Triaged → In Progress |
Changed in charm-kubernetes-worker: | |
status: | Triaged → In Progress |
Changed in charm-kubernetes-master: | |
status: | In Progress → Fix Committed |
Changed in charm-kubernetes-worker: | |
status: | In Progress → Fix Committed |
tags: | removed: review-needed |
Changed in charm-kubernetes-worker: | |
status: | In Progress → Fix Committed |
Changed in charm-kubernetes-master: | |
milestone: | 1.22+ck1 → 1.23 |
Changed in charm-kubernetes-worker: | |
milestone: | 1.22+ck1 → 1.23 |
Changed in charm-kubernetes-master: | |
assignee: | Kevin W Monroe (kwmonroe) → nobody |
milestone: | 1.23 → 1.24 |
Changed in charm-kubernetes-worker: | |
assignee: | Kevin W Monroe (kwmonroe) → nobody |
milestone: | 1.23 → 1.24 |
Changed in charm-kubernetes-master: | |
milestone: | 1.24 → 1.24+ck1 |
Changed in charm-kubernetes-worker: | |
milestone: | 1.24 → 1.24+ck1 |
Changed in charm-kubernetes-master: | |
milestone: | 1.24+ck1 → 1.25 |
Changed in charm-kubernetes-worker: | |
milestone: | 1.24+ck1 → 1.25 |
Changed in charm-kubernetes-master: | |
milestone: | 1.25 → none |
Changed in charm-kubernetes-worker: | |
milestone: | 1.25 → none |
I'm marking this as invalid for the charm, this is a change in snapd that the charm has no control over.
Hopefully there's something snapd can do about graceful fallback in this case to avoid the regression in functionality.