volume stays in an indefinite "backing-up" state when no cinder-backup is running

[Steve Baker]

Creating a backup when cinder-backup is not running results in the following:
- the volume going into state "backing-up"
- the backup going into state "creating"

This state continues indefinitely, even when no backup is actually occurring.

It would be better if this failed immediately with a backup unavailable error.

[Marc Koderer (m-koderer)]

Furthermore if you start cinder-backup all started backups will be set to 'error'.

See backup/manager.py:

115 # TODO(smulcahy) implement full resume of backup and restore
116 # operations on restart (rather than simply resetting)
117 backups = self.db.backup_get_all_by_host(ctxt, self.host)
118 for backup in backups:
119 if backup['status'] == 'creating':
120 LOG.info(_('Resetting backup %s to error '
121 '(was creating)') % backup['id'])
122 err = 'incomplete backup reset on manager restart'
123 self.db.backup_update(ctxt, backup['id'], {'status': 'error',
124 'fail_reason': err})

[OpenStack Infra (hudson-openstack)]

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

[stephen mulcahy (stephen-mulcahy)]

Until someone implements the TODO in line 115, it is better to at least reset things to an error state on restart allowing a user to delete them - rather than leave them forever stuck in a state which the user cannot change.

[Marc Koderer (m-koderer)]

@stephen: aggree, so if the backup fails immediately this would make the workflow much more intuitive. And line 115 won't be execued in this use case.
But anyway if this isn't possible the TODO in 115 should be implemented.

[Xiaoxi Chen (xiaoxi-chen)]

@Marc,
  Agree but I think #line 115 is an other topic , I suggest you just put another bug report for that

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/36612
Committed: http://github.com/openstack/cinder/commit/dbb854635fdb988e28acf87d221fa278e6cb8c0c
Submitter: Jenkins
Branch: master

commit dbb854635fdb988e28acf87d221fa278e6cb8c0c
Author: xiaoxi_chen <email address hidden>
Date: Thu Jul 11 15:22:04 2013 +0800

    Check enabled backup service before rpc request

    In previous code we didn't check whether we have an enabled
    backup service there before we send out the rpc request,
    results that if no enabled backup service there,the volume will
    stays in "backing-up" state and the backup will stays in "creating".

    This patch fixed this issue, we exam whether at least an appropriate
    (same host,az as the volume and is_alive) backup service available
    before we do the rpc request.

    Fixes: bug #1200040
    Change-Id: I77154528f489ed20f7b784e6fcefccf15dc81d1d