Charm fails when zapping loopback device

[Liam Young]

The charm mounts the specified file using loopback device loop0 But subsequent config-change hook runs fail with:

Traceback (most recent call last):
  File "./hooks/config-changed", line 282, in <module>
    main()
  File "./hooks/config-changed", line 273, in main
    hooks.execute(sys.argv)
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/charmhelpers/core/hookenv.py", line 800, in execute
    self._hooks[hook_name]()
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/charmhelpers/core/host.py", line 711, in wrapped_f
    restart_functions)
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/charmhelpers/core/host.py", line 733, in restart_on_change_helper
    r = lambda_f()
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/charmhelpers/core/host.py", line 710, in <lambda>
    (lambda: f(*args, **kwargs)), restart_map, stopstart,
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/charmhelpers/contrib/hardening/harden.py", line 79, in _harden_inner2
    return f(*args, **kwargs)
  File "./hooks/config-changed", line 152, in config_changed
    setup_storage()
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/lib/swift_storage_utils.py", line 479, in setup_storage
    clean_storage(dev)
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/lib/misc_utils.py", line 112, in clean_storage
    zap_disk(block_device)
  File "/var/lib/juju/agents/unit-swift-storage-0/charm/hooks/charmhelpers/contrib/storage/linux/utils.py", line 52, in zap_disk
    'bs=1M', 'count=1'])
  File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['dd', 'if=/dev/zero', 'of=/dev/loop1', 'bs=1M', 'count=1']' returned non-zero exit status 1

[Liam Young (gnuoy)]

This seems to come down to the backing file being associated with
loop0 on initial install. But when the file is mounted a secound
loopback device is used, loop1. The association between loop1 and
the backing file is removed when the file is unmounted. This only
becomes an issue when clean_storage is called. clean_storage unmounts
the filesystem which removes the backing from the loopback device and
then tries to dd the loopback device which fails as it has no file
association. Stepping through in slightly more detail:

1) In setup_storage determine_block_devices is called which
   indirectly calls ensure_loopback_device with the backing file as
   the argument. This loops over the output of 'losetup -a'.
   'losetup -a' returns both loop0 and loop1 but
   ensure_loopback_device returns the first match which happens to be
   loop1
2) clean_storage('/dev/loop1') is then called. The first thing
   clean_storage does is unmount the filesystem using the backing
   file which causes loop1 to be disassociated from the backing file.
   clean_storage then calls zap_disk on loop1 but loop1 is no longer
   associated with a file and so the first dd call fails

[Liam Young (gnuoy)]

$ cat config.yaml
swift-storage:
    zone: 1
    block-device: '/var/local/swift.img|1G'
    overwrite: 'true'

$ juju deploy --series xenial --config config.yaml \
  cs:~openstack-charmers-next/swift-storage-283

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/560009

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/560009
Committed: https://git.openstack.org/cgit/openstack/charm-swift-storage/commit/?id=6346a7458b7cf5c8bb89873dc833f22115fe31de
Submitter: Zuul
Branch: master

commit 6346a7458b7cf5c8bb89873dc833f22115fe31de
Author: Liam Young <email address hidden>
Date: Tue Apr 10 10:49:44 2018 +0000

    Use the loop device in fstab instead of image file

    When adding an fstab entry for a loopback device use the explicit
    loopback device name rather than the source image file. This prevents
    a new loopback device being created implitcitly when mounting the
    image.

    The unit tests needed updating to reflect that the loopback
    device name is used when creating mountpoint names rather than than
    the name of the image file. This was pre-existing behaviour.

    Change-Id: Ide074310bf7121f1179e0b5237dff6f3da88e24e
    Closes-Bug: #1762390