[AWS] not able to spin LXD containers with extra storage
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Original issue: https:/
It seems that Juju has an exclusion that disallows a given non-LXD cloud to deploy LXD containers on a VM with extra storage volumes.
I can see that error explicitly presented in: https:/
I believe what is happening is the following: (1) we deploy a bundle; (2) juju controller processes the bundle and issues separate requests for each part of that bundle; (3) the "0/lxd/0" fails with storage - hence we are seeing an error from juju/cmd in the juju status instead as a return from CLI.
In any case, this is a complicated limitation for us. It means we cannot run a given DB on top of LXDs on any cloud.
Would be better instead if Juju controller could process LXD-type storage requests: receive the request, issue a new volume just like any other workload; then if this is going to LXD, setup a new storage pool in the LXD of that said machine and pass it as a volume to the container.
tags: | added: canonical-data-platform-eng |
As noted, Juju doesn't support this. You're right that we *could* support mounting the EBS volume on the host, and then work throug the mechanics to provide it to LXD, and get it mounted into a container.
We don't have any of that logic today, and it is not exactly trivial to get right, especially with edge cases around when storage shows up, how to do clean setup/teardown/etc.
In general, we haven't prioritized this work because when you are deploying into clouds, you already can size VMs however much you would like, so there isn't much *need* to take a VM and then carve it up into LXD containers.
(Note that you also will have a host of issues around networking and accessibility, etc, so storage is only one of the concerns around containers inside of VMs on arbitrary clouds.)
If there are hard constraints as to why things need to be spun up into containers- inside- VMs, you're welcome to raise it as a request, but you are definitely in "this has never been supported, so cannot be considered a bug" territory.