Loopback mounts do not work with local provider, use directory storage

Bug #1250965 reported by Stuart Bishop on 2013-11-13
26
This bug affects 4 people
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://osdir.com/ml/lxc-chroot-linux-containers/2013-01/msg00036.html

The charm fails when it tries to run losetup.

# losetup --find /etc/swift/storagedev1.img
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/3.11.0-13-generic/modules.dep: No such file or directory

Curtis Hovey (sinzui) on 2013-11-13
summary: - Does not work with local provider
+ Loopback mounts do not work with local provider
tags: added: local-provider
Curtis Hovey (sinzui) on 2013-11-18
Changed in juju-core:
status: New → Triaged
importance: Undecided → High
Stuart Bishop (stub) wrote :

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 :

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
Curtis Hovey (sinzui) on 2014-05-13
Changed in juju-core:
importance: High → Medium
Martin Pitt (pitti) wrote :

Swift can definitively do that. http://www.piware.de/2014/03/creating-a-local-swift-server-on-ubuntu-for-testing/ describes what I did for that, and http://people.canonical.com/~pitti/scripts/setup-swift.sh is the script to run in a container to set up everything. The important bit here is to set "mount_check = false" and "devices = /srv/swift/" (or whichever other directory you use) in object-server.conf.

Martin Pitt (pitti) wrote :

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
Curtis Hovey (sinzui) on 2016-04-24
Changed in juju-core:
importance: Medium → Low
Changed in juju-core:
status: Triaged → Won't Fix
James Page (james-page) on 2017-01-04
Changed in swift-storage (Juju Charms Collection):
importance: Undecided → Wishlist
status: Confirmed → Triaged
Heather Lanigan (hmlanigan) wrote :

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?

James Page (james-page) on 2017-02-23
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 :

Adding another +1 to wanting swift-storage to allow for directory/mountpoints in swift-storage charm's block-devices as we can use with ceph storage.

Odd, but important use case:

bcache bypass using /dev/loop0 to mount the backing store (8k offset, losetup -o 8192 /dev/loop0 /dev/$bcache_backing_device) and then mounting /dev/loop0 to /srv/node/bcache0 where bcache lived before.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers