[Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing
The update to 3.4.0 beta2 was very smooth. My 3.3.3 setup was very basic so my testing was not extremely extensive, but I wanted to make sure I could still override NFS mount options (I could) to ensure use of RDMA. Now I'd like to downgrade, but that was not as simple as I'd hoped. I could not find any definitive docs on the subject so pieced together the steps. # Backup 3.3.3 $ engine-backup --mode=backup --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log # Enabled the 3.4.0 repo per release notes $ yum update ovirt-engine-setup $ engine-setup # I tested 3.4.0 and wanted to "downgrade". $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log FATAL: Engine service is active - can not restore backup $ /etc/init.d/ovirt-engine stop $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Backup version '3.3' doesn't match installed version # Disabled the 3.4.0 repo $ yum downgrade ovirt-engine-setup-3.3.3-2.el6 Loaded plugins: downloadonly, fastestmirror, security, versionlock Setting up Downgrade Process Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-setup.noarch 0:3.3.3-2.el6 will be a downgrade ---> Package ovirt-engine-setup.noarch 0:3.4.0-0.7.beta2.el6 will be erased --> Finished Dependency Resolution Error: Package: ovirt-engine-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) Requires: ovirt-engine-setup >= 3.4.0-0.7.beta2.el6 Removing: ovirt-engine-setup-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) ovirt-engine-setup = 3.4.0-0.7.beta2.el6 Downgraded By: ovirt-engine-setup-3.3.3-2.el6.noarch (ovirt-3.3.3) ovirt-engine-setup = 3.3.3-2.el6 Available: ovirt-engine-setup-3.3.0-4.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0-4.el6 Available: ovirt-engine-setup-3.3.0.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0.1-1.el6 Available: ovirt-engine-setup-3.3.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-1.el6 Available: ovirt-engine-setup-3.3.1-2.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-2.el6 Available: ovirt-engine-setup-3.3.2-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.2-1.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest # Re-enabled the 3.4.0 repo $ yum downgrade ovirt-engine-setup-3.3.3-2.el6 Loaded plugins: downloadonly, fastestmirror, security, versionlock Setting up Downgrade Process Loading mirror speeds from cached hostfile ovirt-3.3.3 | 2.9 kB 00:00 ovirt-3.4.0-prerelease | 3.4 kB 00:00 ovirt-stable | 2.9 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-setup.noarch 0:3.3.3-2.el6 will be a downgrade ---> Package ovirt-engine-setup.noarch 0:3.4.0-0.7.beta2.el6 will be erased --> Finished Dependency Resolution Error: Package: ovirt-engine-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) Requires: ovirt-engine-setup >= 3.4.0-0.7.beta2.el6 Removing: ovirt-engine-setup-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) ovirt-engine-setup = 3.4.0-0.7.beta2.el6 Downgraded By: ovirt-engine-setup-3.3.3-2.el6.noarch (ovirt-3.3.3) ovirt-engine-setup = 3.3.3-2.el6 Available: ovirt-engine-setup-3.3.0-4.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0-4.el6 Available: ovirt-engine-setup-3.3.0.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0.1-1.el6 Available: ovirt-engine-setup-3.3.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-1.el6 Available: ovirt-engine-setup-3.3.1-2.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-2.el6 Available: ovirt-engine-setup-3.3.2-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.2-1.el6 Available: ovirt-engine-setup-3.4.0-0.5.beta1.el6.noarch (ovirt-3.4.0-prerelease) ovirt-engine-setup = 3.4.0-0.5.beta1.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest # Disable 3.4.0 repo again $ yum remove ovirt-engine-setup ovirt-engine-setup-base $ yum install ovirt-engine-setup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty $ engine-cleanup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty Attached are the two engine-cleanup logs from both attempts. The first (from 20140211) was answering "Yes" only to "remove Engine DB content". The second (from 20140212, today) was "Yes" to "remove all components". Thanks - Trey
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "users" <users@ovirt.org> Sent: Wednesday, February 12, 2014 8:19:25 PM Subject: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing
The update to 3.4.0 beta2 was very smooth. My 3.3.3 setup was very basic so my testing was not extremely extensive, but I wanted to make sure I could still override NFS mount options (I could) to ensure use of RDMA.
Now I'd like to downgrade, but that was not as simple as I'd hoped. I could not find any definitive docs on the subject so pieced together the steps.
# Backup 3.3.3 $ engine-backup --mode=backup --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log
# Enabled the 3.4.0 repo per release notes $ yum update ovirt-engine-setup $ engine-setup
# I tested 3.4.0 and wanted to "downgrade".
$ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log FATAL: Engine service is active - can not restore backup
$ /etc/init.d/ovirt-engine stop
$ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Backup version '3.3' doesn't match installed version
# Disabled the 3.4.0 repo $ yum downgrade ovirt-engine-setup-3.3.3-2.el6 Loaded plugins: downloadonly, fastestmirror, security, versionlock Setting up Downgrade Process Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-setup.noarch 0:3.3.3-2.el6 will be a downgrade ---> Package ovirt-engine-setup.noarch 0:3.4.0-0.7.beta2.el6 will be erased --> Finished Dependency Resolution Error: Package: ovirt-engine-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) Requires: ovirt-engine-setup >= 3.4.0-0.7.beta2.el6 Removing: ovirt-engine-setup-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) ovirt-engine-setup = 3.4.0-0.7.beta2.el6 Downgraded By: ovirt-engine-setup-3.3.3-2.el6.noarch (ovirt-3.3.3) ovirt-engine-setup = 3.3.3-2.el6 Available: ovirt-engine-setup-3.3.0-4.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0-4.el6 Available: ovirt-engine-setup-3.3.0.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0.1-1.el6 Available: ovirt-engine-setup-3.3.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-1.el6 Available: ovirt-engine-setup-3.3.1-2.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-2.el6 Available: ovirt-engine-setup-3.3.2-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.2-1.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
# Re-enabled the 3.4.0 repo $ yum downgrade ovirt-engine-setup-3.3.3-2.el6 Loaded plugins: downloadonly, fastestmirror, security, versionlock Setting up Downgrade Process Loading mirror speeds from cached hostfile ovirt-3.3.3
| 2.9 kB 00:00 ovirt-3.4.0-prerelease
| 3.4 kB 00:00 ovirt-stable
| 2.9 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-setup.noarch 0:3.3.3-2.el6 will be a downgrade ---> Package ovirt-engine-setup.noarch 0:3.4.0-0.7.beta2.el6 will be erased --> Finished Dependency Resolution Error: Package: ovirt-engine-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) Requires: ovirt-engine-setup >= 3.4.0-0.7.beta2.el6 Removing: ovirt-engine-setup-3.4.0-0.7.beta2.el6.noarch (@ovirt-3.4.0-prerelease) ovirt-engine-setup = 3.4.0-0.7.beta2.el6 Downgraded By: ovirt-engine-setup-3.3.3-2.el6.noarch (ovirt-3.3.3) ovirt-engine-setup = 3.3.3-2.el6 Available: ovirt-engine-setup-3.3.0-4.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0-4.el6 Available: ovirt-engine-setup-3.3.0.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.0.1-1.el6 Available: ovirt-engine-setup-3.3.1-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-1.el6 Available: ovirt-engine-setup-3.3.1-2.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.1-2.el6 Available: ovirt-engine-setup-3.3.2-1.el6.noarch (ovirt-stable) ovirt-engine-setup = 3.3.2-1.el6 Available: ovirt-engine-setup-3.4.0-0.5.beta1.el6.noarch (ovirt-3.4.0-prerelease) ovirt-engine-setup = 3.4.0-0.5.beta1.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
# Disable 3.4.0 repo again $ yum remove ovirt-engine-setup ovirt-engine-setup-base $ yum install ovirt-engine-setup
$ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty
$ engine-cleanup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty
Attached are the two engine-cleanup logs from both attempts. The first (from 20140211) was answering "Yes" only to "remove Engine DB content". The second (from 20140212, today) was "Yes" to "remove all components".
Apparently engine-cleanup does not clean up everything. We tried to make it do that, and I am pretty certain it used to at some point... 1. You might want to open a bug about this. As you already posted, manually dropping and creating the database still works... 2. Adding infra@ - I think we should add a jenkins job to verify that engine-cleanup cleans up at least the database, perhaps other things. I am pretty certain it should be so for 3.3, didn't check 3.4 yet. Best regards, -- Didi
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Trey Dockendorf" <treydock@gmail.com> Cc: "users" <users@ovirt.org>, infra@ovirt.org Sent: Thursday, February 13, 2014 8:32:01 AM Subject: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "users" <users@ovirt.org> Sent: Wednesday, February 12, 2014 8:19:25 PM Subject: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing $ engine-cleanup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty
Attached are the two engine-cleanup logs from both attempts. The first (from 20140211) was answering "Yes" only to "remove Engine DB content". The second (from 20140212, today) was "Yes" to "remove all components".
Apparently engine-cleanup does not clean up everything. We tried to make it do that, and I am pretty certain it used to at some point...
1. You might want to open a bug about this. As you already posted, manually dropping and creating the database still works... 2. Adding infra@ - I think we should add a jenkins job to verify that engine-cleanup cleans up at least the database, perhaps other things. I am pretty certain it should be so for 3.3, didn't check 3.4 yet.
Well, I now tried that with 3.4.0-beta2 and did not manage to reproduce - database was empty after engine-cleanup. If you manage to reproduce, please post the output of: pg_dump engine | grep -i ^create (as postgres, or passing credentials as needed). It should only output one line: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog; If it outputs anything else it's probably a bug. Thanks, FYI, -- Didi
On Thu, Feb 13, 2014 at 1:55 AM, Yedidyah Bar David <didi@redhat.com> wrote:
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Trey Dockendorf" <treydock@gmail.com> Cc: "users" <users@ovirt.org>, infra@ovirt.org Sent: Thursday, February 13, 2014 8:32:01 AM Subject: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "users" <users@ovirt.org> Sent: Wednesday, February 12, 2014 8:19:25 PM Subject: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing $ engine-cleanup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty
Attached are the two engine-cleanup logs from both attempts. The first (from 20140211) was answering "Yes" only to "remove Engine DB content". The second (from 20140212, today) was "Yes" to "remove all components".
Apparently engine-cleanup does not clean up everything. We tried to make it do that, and I am pretty certain it used to at some point...
1. You might want to open a bug about this. As you already posted, manually dropping and creating the database still works... 2. Adding infra@ - I think we should add a jenkins job to verify that engine-cleanup cleans up at least the database, perhaps other things. I am pretty certain it should be so for 3.3, didn't check 3.4 yet.
Well, I now tried that with 3.4.0-beta2 and did not manage to reproduce - database was empty after engine-cleanup.
If you manage to reproduce, please post the output of: pg_dump engine | grep -i ^create (as postgres, or passing credentials as needed). It should only output one line: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
If it outputs anything else it's probably a bug.
Thanks, FYI, -- Didi
With 3.3.3 I got this after engine-cleanup. (/root/pgpass was created by me mimicking what's created by engine-backup). $ PGPASSFILE=/root/pgpass pg_dump -U engine -h localhost -p 5432 engine | grep -vi '^create extension' | grep -i '^create' CREATE PROCEDURAL LANGUAGE plpgsql; The grep statements above mimic what was executed by the engine-backup which resulted in a message "FATAL: Database is not empty". I will try and reproduce with 3.4.0-beta2. Should I file a bug for this issue against 3.3.x? Thanks - Trey
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "users" <users@ovirt.org>, "infra" <infra@ovirt.org> Sent: Thursday, February 13, 2014 7:36:52 PM Subject: Re: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
On Thu, Feb 13, 2014 at 1:55 AM, Yedidyah Bar David <didi@redhat.com> wrote:
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Trey Dockendorf" <treydock@gmail.com> Cc: "users" <users@ovirt.org>, infra@ovirt.org Sent: Thursday, February 13, 2014 8:32:01 AM Subject: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "users" <users@ovirt.org> Sent: Wednesday, February 12, 2014 8:19:25 PM Subject: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing $ engine-cleanup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty
Attached are the two engine-cleanup logs from both attempts. The first (from 20140211) was answering "Yes" only to "remove Engine DB content". The second (from 20140212, today) was "Yes" to "remove all components".
Apparently engine-cleanup does not clean up everything. We tried to make it do that, and I am pretty certain it used to at some point...
1. You might want to open a bug about this. As you already posted, manually dropping and creating the database still works... 2. Adding infra@ - I think we should add a jenkins job to verify that engine-cleanup cleans up at least the database, perhaps other things. I am pretty certain it should be so for 3.3, didn't check 3.4 yet.
Well, I now tried that with 3.4.0-beta2 and did not manage to reproduce - database was empty after engine-cleanup.
If you manage to reproduce, please post the output of: pg_dump engine | grep -i ^create (as postgres, or passing credentials as needed). It should only output one line: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
If it outputs anything else it's probably a bug.
Thanks, FYI, -- Didi
With 3.3.3 I got this after engine-cleanup.
(/root/pgpass was created by me mimicking what's created by engine-backup).
$ PGPASSFILE=/root/pgpass pg_dump -U engine -h localhost -p 5432 engine | grep -vi '^create extension' | grep -i '^create' CREATE PROCEDURAL LANGUAGE plpgsql;
OK, makes (some?) sense... Eli - How come it does not always appear in pg_dump's outout? Is it because it's not always created, or not always output, or something else?
The grep statements above mimic what was executed by the engine-backup which resulted in a message "FATAL: Database is not empty".
I will try and reproduce with 3.4.0-beta2.
Should I file a bug for this issue against 3.3.x?
Please do! Thanks for the report, -- Didi
Submitted against 3.3.3, https://bugzilla.redhat.com/show_bug.cgi?id=1066654 I am in process of installing 3.4.0-betaN to see if this only effects 3.3.3. - Trey On Sun, Feb 16, 2014 at 5:01 AM, Yedidyah Bar David <didi@redhat.com> wrote:
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "users" <users@ovirt.org>, "infra" <infra@ovirt.org> Sent: Thursday, February 13, 2014 7:36:52 PM Subject: Re: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
On Thu, Feb 13, 2014 at 1:55 AM, Yedidyah Bar David <didi@redhat.com> wrote:
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Trey Dockendorf" <treydock@gmail.com> Cc: "users" <users@ovirt.org>, infra@ovirt.org Sent: Thursday, February 13, 2014 8:32:01 AM Subject: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "users" <users@ovirt.org> Sent: Wednesday, February 12, 2014 8:19:25 PM Subject: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing $ engine-cleanup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty
Attached are the two engine-cleanup logs from both attempts. The first (from 20140211) was answering "Yes" only to "remove Engine DB content". The second (from 20140212, today) was "Yes" to "remove all components".
Apparently engine-cleanup does not clean up everything. We tried to make it do that, and I am pretty certain it used to at some point...
1. You might want to open a bug about this. As you already posted, manually dropping and creating the database still works... 2. Adding infra@ - I think we should add a jenkins job to verify that engine-cleanup cleans up at least the database, perhaps other things. I am pretty certain it should be so for 3.3, didn't check 3.4 yet.
Well, I now tried that with 3.4.0-beta2 and did not manage to reproduce - database was empty after engine-cleanup.
If you manage to reproduce, please post the output of: pg_dump engine | grep -i ^create (as postgres, or passing credentials as needed). It should only output one line: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
If it outputs anything else it's probably a bug.
Thanks, FYI, -- Didi
With 3.3.3 I got this after engine-cleanup.
(/root/pgpass was created by me mimicking what's created by engine-backup).
$ PGPASSFILE=/root/pgpass pg_dump -U engine -h localhost -p 5432 engine | grep -vi '^create extension' | grep -i '^create' CREATE PROCEDURAL LANGUAGE plpgsql;
OK, makes (some?) sense... Eli - How come it does not always appear in pg_dump's outout? Is it because it's not always created, or not always output, or something else?
The grep statements above mimic what was executed by the engine-backup which resulted in a message "FATAL: Database is not empty".
I will try and reproduce with 3.4.0-beta2.
Should I file a bug for this issue against 3.3.x?
Please do!
Thanks for the report, -- Didi
I just tried same steps with 3.4.0-beta2 and got same results. Performed full 'engine-cleanup' and a engine-backup --mode=restore failed with "FATAL: Database is not empty" $ su - postgres -c "pg_dump engine | grep -i ^create" CREATE PROCEDURAL LANGUAGE plpgsql; After the failed restore the following two commands were enough to allow restore to run. $ su - postgres -c "dropdb engine" $ su - postgres -c "psql -c \"create database engine owner engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8'\"" - Trey On Tue, Feb 18, 2014 at 2:32 PM, Trey Dockendorf <treydock@gmail.com> wrote:
Submitted against 3.3.3, https://bugzilla.redhat.com/show_bug.cgi?id=1066654
I am in process of installing 3.4.0-betaN to see if this only effects 3.3.3.
- Trey
On Sun, Feb 16, 2014 at 5:01 AM, Yedidyah Bar David <didi@redhat.com> wrote:
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "users" <users@ovirt.org>, "infra" <infra@ovirt.org> Sent: Thursday, February 13, 2014 7:36:52 PM Subject: Re: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
On Thu, Feb 13, 2014 at 1:55 AM, Yedidyah Bar David <didi@redhat.com> wrote:
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Trey Dockendorf" <treydock@gmail.com> Cc: "users" <users@ovirt.org>, infra@ovirt.org Sent: Thursday, February 13, 2014 8:32:01 AM Subject: eninge-cleanup left db non-empty (was: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing)
----- Original Message -----
From: "Trey Dockendorf" <treydock@gmail.com> To: "users" <users@ovirt.org> Sent: Wednesday, February 12, 2014 8:19:25 PM Subject: [Users] Downgrading to 3.3.3 after 3.4.0 beta 2 testing $ engine-cleanup $ engine-backup --mode=restore --scope=all --file=engine-20140211-1457.tar.bz2 --log=engine-backup.log Restoring... FATAL: Database is not empty
Attached are the two engine-cleanup logs from both attempts. The first (from 20140211) was answering "Yes" only to "remove Engine DB content". The second (from 20140212, today) was "Yes" to "remove all components".
Apparently engine-cleanup does not clean up everything. We tried to make it do that, and I am pretty certain it used to at some point...
1. You might want to open a bug about this. As you already posted, manually dropping and creating the database still works... 2. Adding infra@ - I think we should add a jenkins job to verify that engine-cleanup cleans up at least the database, perhaps other things. I am pretty certain it should be so for 3.3, didn't check 3.4 yet.
Well, I now tried that with 3.4.0-beta2 and did not manage to reproduce - database was empty after engine-cleanup.
If you manage to reproduce, please post the output of: pg_dump engine | grep -i ^create (as postgres, or passing credentials as needed). It should only output one line: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
If it outputs anything else it's probably a bug.
Thanks, FYI, -- Didi
With 3.3.3 I got this after engine-cleanup.
(/root/pgpass was created by me mimicking what's created by engine-backup).
$ PGPASSFILE=/root/pgpass pg_dump -U engine -h localhost -p 5432 engine | grep -vi '^create extension' | grep -i '^create' CREATE PROCEDURAL LANGUAGE plpgsql;
OK, makes (some?) sense... Eli - How come it does not always appear in pg_dump's outout? Is it because it's not always created, or not always output, or something else?
The grep statements above mimic what was executed by the engine-backup which resulted in a message "FATAL: Database is not empty".
I will try and reproduce with 3.4.0-beta2.
Should I file a bug for this issue against 3.3.x?
Please do!
Thanks for the report, -- Didi
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (2)
-
Trey Dockendorf -
Yedidyah Bar David