Loopback mounts do not work with local provider, use directory storage
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| OpenStack swift-storage charm |
Wishlist
|
Unassigned | ||
| juju-core |
Low
|
Unassigned | ||
| swift-storage (Juju Charms Collection) |
Wishlist
|
Unassigned |
Bug Description
The swift-storage charm needs to use loopback mounts, but these don't appear to work under LXC unless you tweak the default templates per http://
The charm fails when it tries to run losetup.
# losetup --find /etc/swift/
losetup: Could not find any loop device. Maybe this kernel does not know
about the loop device? (If so, recompile or `modprobe loop'.)
# modprobe loop
FATAL: Could not load /lib/modules/
summary: |
- Does not work with local provider + Loopback mounts do not work with local provider |
tags: | added: local-provider |
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → High |
Stuart Bishop (stub) wrote : | #2 |
I doubt there is anything to do at the Swift charm end,, flagging as INVALID there.
Changed in swift-storage (Juju Charms Collection): | |
status: | New → Invalid |
Stuart Bishop (stub) wrote : | #3 |
Can the Swift charm make use of alternative storage that doesn't require a loop device?
Changed in swift-storage (Juju Charms Collection): | |
status: | Invalid → New |
Changed in juju-core: | |
importance: | High → Medium |
Martin Pitt (pitti) wrote : | #4 |
Swift can definitively do that. http://
Martin Pitt (pitti) wrote : | #5 |
BTW, I see little value in using a loopback mount even for "real" clouds; that will still be QEMU, so a directory storage will be at least equal to, or even faster than an image file through loopback.
Changed in swift-storage (Juju Charms Collection): | |
status: | New → Confirmed |
summary: |
- Loopback mounts do not work with local provider + Loopback mounts do not work with local provider, use directory storage |
tags: | added: openstack |
Changed in juju-core: | |
importance: | Medium → Low |
Changed in juju-core: | |
status: | Triaged → Won't Fix |
Changed in swift-storage (Juju Charms Collection): | |
importance: | Undecided → Wishlist |
status: | Confirmed → Triaged |
Heather Lanigan (hmlanigan) wrote : | #6 |
It'd be nice to have this. I ran into the same issue. I'm trying to use the Glance Simplestreams Sync charm with the openstack-novalxd bundle. Deployed swift for it and ran into this problem.
Or could the Glance Simplestreams Sync charm using other container options as well?
Changed in charm-swift-storage: | |
importance: | Undecided → Wishlist |
status: | New → Triaged |
Changed in swift-storage (Juju Charms Collection): | |
status: | Triaged → Invalid |
Drew Freiberger (afreiberger) wrote : | #7 |
Adding another +1 to wanting swift-storage to allow for directory/
Odd, but important use case:
bcache bypass using /dev/loop0 to mount the backing store (8k offset, losetup -o 8192 /dev/loop0 /dev/$bcache_
This appears to be a known issue: comments. gmane.org/ gmane.linux. kernel. containers. lxc.general/ 4537 askubuntu. com/questions/ 141552/ creating- volume- group-in- nova-volume- juju-charm
http://
http://