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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
