Bug 1188130

(In reply to Yaniv Dary from comment #0)
> Description of problem:
> In order to prevent issues with restore with unfinished tasks, engine-back
> will wait for a configurable amount to start backup, if async tasks are
> running, and will retry for configurable amount of times before failing on
> inability to run due to tasks running.

How to check these?

How to configure?

> 
> This can be also resolved by not backing up these tasks at all.

How?

Please update the wiki and/or add other relevant links.

Also, is the system supposed to work well with some tables not backed up at all? If we want just the schema, pg_dump of 9.2 has an option '--exclude-table-data'.

Also, I do not really understand why we need this bug. Since 3.4, we require running engine-setup immediately after finishing restore, and before the engine is started. This AFAIU should be enough to clean up async tasks and similar stuff.

After a discussion with Oved:

I need a list of tables that should be emptied by a backup/restore cycle. Eli - please provide this list.

Current plan is to leave backup untouched, and empty these tables on restore. This will be much simpler.

I think I'll add an option to not do that, something like --keep-temporary-data or something like that.

Comments are welcome.

I don't think that this is the right approach to go
You may backup the system anytime, removing the temporary data while engine is running is dangerous
I prefer that engine-backup will expose the pg_dump -T parameter

(In reply to Eli Mesika from comment #3)
> I don't think that this is the right approach to go
> You may backup the system anytime, removing the temporary data while engine
> is running is dangerous

That's why I proposed to do this on restore

> I prefer that engine-backup will expose the pg_dump -T parameter

This means the tables will not be available at all after restore, instead of being empty. pg 9.2 has '--exclude-table-data' but el6 has 8.4, so we can't use that.

List of tables :

async_tasks
async_tasks_entities
business_entity_snapshot
command_entities
job
step

With the current pending patch in gerrit, the log says:

2015-04-19 17:17:19 14876: Cleaning up temporary tables in engine database 'engine':
2015-04-19 17:17:19 14876: - async_tasks
NOTICE:  truncate cascades to table "async_tasks_entities"
TRUNCATE TABLE
2015-04-19 17:17:20 14876: - async_tasks_entities
TRUNCATE TABLE
2015-04-19 17:17:20 14876: - business_entity_snapshot
TRUNCATE TABLE
2015-04-19 17:17:20 14876: - command_entities
TRUNCATE TABLE
2015-04-19 17:17:20 14876: - job
NOTICE:  truncate cascades to table "step"
NOTICE:  truncate cascades to table "job_subject_entity"
TRUNCATE TABLE
2015-04-19 17:17:20 14876: - step
TRUNCATE TABLE

That is, in addition to the ones in comment 5,
NOTICE:  truncate cascades to table "job_subject_entity"

Is that ok/expected?

(In reply to Yedidyah Bar David from comment #6)
> With the current pending patch in gerrit, the log says:

Yes, cascaded operations resulted from deleting a record which have a PK that is defined in other table as FK ON CASCADE DELETE , is OK

Created attachment 1044949 [details]
engine backup db results with async tasks

Verified with:
ovirt-engine-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch

Added a host to the engine and ran engine-backup while running task.
Results from db attached.

After restore, the tables async_tasks, async_tasks_entities, business_entity_snapshot, command_entities, job and step remain empty.

oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.