You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
flotter
changed the title
Allow craft tools to function inside a LXD container parent
Allow craft tools to function inside a LXD parent container when performing a LXD managed build
Oct 5, 2024
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.
The text was updated successfully, but these errors were encountered: