canonical-ci-engineering team mailing list archive
-
canonical-ci-engineering team
-
Mailing list archive
-
Message #00766
Re: Leveraging Swift TempUrl feature and integration tests
This was a superb read. Thank you.
On 17 April 2014 05:27, Celso Providelo <celso.providelo@xxxxxxxxxxxxx> wrote:
> I ended up adjusting a shell script stollen from Martin Pitti [5] for
> creating and configuring a bare swift instance within a LXC container.
I think if we're going down the road of Swift in LXC, we should
eventually use the charm in the Juju local provider. Unfortunately,
this is complicated by Swift needing a block device.
I tried to get this going using a loop-mounted filesystem exposed to
the LXC container using lxc-device, however it did not want to
cooperate¹:
Apr 18 00:56:01 poppy-dev kernel: [254510.331008] type=1400
audit(1397778961.922:96): apparmor="DENIED" operation="mount"
info="failed type match" error=-13 profile="lxc-container-default"
name="/mnt/" pid=24222 comm="mount" fstype="ext3"
srcname="/dev/loop1/" flags="rw"
I ultimately worked around it by loosening the apparmor restrictions
on lxc, adding "mount options=(rw) /dev/loop*/" to
/etc/apparmor.d/lxc/lxc-default.
sudo dd if=/dev/zero of=swift-disk bs=1M count=1024
sudo mkfs.ext4 swift-disk
DEVICE=$(sudo losetup -f swift-disk --show)
juju deploy cs:swift-storage
sudo lxc-device -n evan-local-machine-1 add $DEVICE
juju set swift-storage block-device=$DEVICE
juju resolved --retry swift-storage/0 # yay volume chicken and egg
And that's enough to make juju happy. A better solution would be to
teach the Swift charm to use non-block local storage.
¹: https://bugs.launchpad.net/charms/+source/swift-storage/+bug/1250965
References