yahoo-eng-team team mailing list archive

[Uggla <2089007@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Description
===========
While there's an access lock, backup of the share can't be done.. because we cannot preserve consistency... today, since attachments aren't known to manila, we've only documented this limitation.. but, with access locks, we know that nova has attached a share)

We should consider this a bug in manila


Steps to reproduce
==================
1-demo user creates a share a VM, attaches the share to the VM, log in to the VM, mount the share and write to it.
2- demo user calls openstack share backup create <share uuid>
3- the backup creation succeeds
4- but the mount in the guest VM becomes failed
   * remount in the guest does not help
   * guest soft reboot initiated within the guest does not help
   *hard reboot with openstack server reboot --hard fails with a nova error. (nova tries to mount the share and fails)


Expected result
===============
Block the backup if there is a lock.

Actual result
=============
The share access gets deleted during the share backup procedure as after the backup I see n no share access no share lock on the share in question.

Environment
===========
Epoxy
DevStack

Workaround
==========
Today nova keeps the share locked even if the VM is stopped.
The manual backup process should be:
stop the VM
detach the share from the VM (nova removes the lock)
do the backup via manila API
attach the share back to the VM (nova locks again)
start the VM

** Affects: nova
     Importance: Undecided
         Status: Triaged

** Changed in: nova
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2089007

Title:
  Share backup cannot be supported if used by Nova

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  Description
  ===========
  While there's an access lock, backup of the share can't be done.. because we cannot preserve consistency... today, since attachments aren't known to manila, we've only documented this limitation.. but, with access locks, we know that nova has attached a share)

  We should consider this a bug in manila

  
  Steps to reproduce
  ==================
  1-demo user creates a share a VM, attaches the share to the VM, log in to the VM, mount the share and write to it.
  2- demo user calls openstack share backup create <share uuid>
  3- the backup creation succeeds
  4- but the mount in the guest VM becomes failed
     * remount in the guest does not help
     * guest soft reboot initiated within the guest does not help
     *hard reboot with openstack server reboot --hard fails with a nova error. (nova tries to mount the share and fails)

  
  Expected result
  ===============
  Block the backup if there is a lock.

  Actual result
  =============
  The share access gets deleted during the share backup procedure as after the backup I see n no share access no share lock on the share in question.

  Environment
  ===========
  Epoxy
  DevStack

  Workaround
  ==========
  Today nova keeps the share locked even if the VM is stopped.
  The manual backup process should be:
  stop the VM
  detach the share from the VM (nova removes the lock)
  do the backup via manila API
  attach the share back to the VM (nova locks again)
  start the VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2089007/+subscriptions