← Back to issue list

Allow craft tools to function inside a LXD parent container when performing a LXD managed build

View original Github issue

Metadata

Project
craft-application
Number
#506
Type
issue
State
open
Author
flotter
Labels
Type: Enhancement
Created
Updated
Closed
—

Current evaluation

Request to support nested LXD managed builds (craft tools in a LXD parent container, e.g. Spread LXD backend), needing idmap range agreement. Maintainer asked for workaround details in Oct 2024; no reporter response since.

Suggested action: close stale

Reason: The issue is labelled Type: Enhancement and was triaged, but the maintainer (mr-cal, 2024-10-07) asked 'Can you specify what workarounds you did?' and the reporter has not responded for ~12 months (last activity 362 days ago), exceeding the 6-month threshold for an unanswered information request. The underlying idmap handling is still hardcoded in craft-providers (lxd_instance.py:410), so the feature remains unimplemented, but the unanswered detail request justifies closing as stale.

Impact: 45 Quick Win: 15.75 Staleness: 75 Complexity: 65 Confidence: 78 Support Request: 10

Issue body

### What needs to get done Please refer to this: https://ubuntu.com/blog/nested-containers-in-lxd Currently when using spread with a LXD backend, running a craft tool does not appear to be supported using a nested LXD managed build backend. If this is actually supported, then this request is not needed ? Supporting nested LXD instances in unprivileged containers require both the LXD parent and the LXD child container to have some agreements with regards to idmap ranges. This feels like a great feature than can be solved inside the common craft libraries, with a documented requirement for the LXD parent container to support this usage case. Here are some resources on the topic: https://documentation.ubuntu.com/lxd/en/latest/userns-idmap/ ### Why it needs to get done This would expand the places where craft tools would "just work" without requiring provider specific tweaks. One use case is Spread LXD backend running craft tools suing managed builds.

Evaluation history

Date Model Scores Action Summary
qwen/qwen3.8-27b
Impact: 45
Quick Win: 15.75
Staleness: 75
Complexity: 65
Confidence: 78
Support Request: 10
close stale Request to support nested LXD managed builds (craft tools in a LXD parent container, e.g. Spread LXD backend), needing idmap range agreement. Maintainer asked for workaround details in Oct 2024; no reporter response since.
qwen/qwen3.6-35b-a3b
Staleness: 85
Complexity: 65
Confidence: 80
Support Request: 20
close stale Enhancement request to support nested LXD instances in unprivileged containers for craft tools. Lacks UID mapping configuration. Maintainer requested workarounds 10 months ago with no response, leaving it unaddressed.
qwen3.6-35b-a3b-mtp-q6
Staleness: 75
Complexity: 60
Confidence: 60
Support Request: 30
close stale Enhancement request to support nested LXD managed builds by configuring UID mappings for craft tools inside LXD parent containers. Inactive for over a year with no response to maintainer's request for workarounds.
qwen3.6-35b-a3b-mtp-q6
Staleness: 75
Complexity: 65
Confidence: 70
Support Request: 10
keep open Enable craft tools in nested LXD managed builds by supporting idmap ranges. craft-providers currently lacks exposed UID settings. Open enhancement under discussion, awaiting workaround details or upstream LXD configuration fixes.

Update history

No update history recorded yet.

Related work

  • Related To: canonical/craft-providers#259 (confidence 90%)

    Maintainer comment states this has a similar underpinning to the UID configuration in craft-providers#259 (open, stalled with a workaround available).

Related issues

No related issues found above the similarity threshold.