Re: [Users] Fedora upgrading from 3.1 to 3.2

From: "Alex Lourie" <alourie(a)redhat.com&gt; To: "Karli Sjöberg" <Karli.Sjoberg(a)slu.se&gt; Cc: users(a)ovirt.org Sent: Wednesday, July 10, 2013 7:16:02 PM Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2 Hi Karli 'Restore' certificates basically means taking the backup of /etc/pki/ovirt-engine/certs and /keys and restoring them into 3.2 after installation. --dont-drop-database will do exactly that - leave DB intact; that can be for your benefit in some cases. I'll be happy to hear on your progress. -- Best regards, Alex Lourie Software Developer in Integration Red Hat ----- Original Message ----- > From: "Karli Sjöberg" <Karli.Sjoberg(a)slu.se&gt; > To: "Alex Lourie" <alourie(a)redhat.com&gt; > Cc: users(a)ovirt.org > Sent: Friday, July 5, 2013 8:34:22 PM > Subject: SV: [Users] Fedora upgrading from 3.1 to 3.2 > > Hi Alex, > > crappy MS webmail that can´t figure out indents while on vacation, just > FYI. > Yes, progress is always good:) I would like to have some pointers about nr. > 4: Restore certificates. Then I can ask one of my co-workers to test the > procedure and report back. So, restore certs; How to? > > Or! I saw in another thread there was a "engine-cleanup --dont-drop-dbase" > something or other... Is there an equivalent for "engine-setup", like > "--dont-touch-dbase"? Or "engine-cleanup --dbase-something" and then > "engine-setup" again, and it´ll just play nice with the dbase that´s still > there perhaps? > > /Karli > > ________________________________________ > Från: Alex Lourie [alourie(a)redhat.com] > Skickat: den 30 juni 2013 17:29 > Till: Karli Sjöberg > Cc: users(a)ovirt.org > Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2 > > Hi Karli > > On Wed, Jun 26, 2013 at 5:28 PM, Karli Sjöberg <Karli.Sjoberg(a)slu.se&gt; > wrote: > > Update! > > > > I have actually made some headway, I managed to get it passed the > > database upgrade! As I was looking at the log, I drilled down into > > the engine-upgrade script at looked at what it was trying to do, > > which was a pythonic way of doing: > > # cd /usr/share/ovirt-engine/dbscripts > > # ./upgrade.sh -s localhost -p 5432 -u engine -d engine > > > > Nice progress! > > > > > So I first reinstalled everything (I´ve stopped counting) and an > > hour later I was back at just before doing engine-upgrade again. What > > I did then was to upgrade ovirt-engine-dbscripts first and ran the > > upgrade.sh script manually (which went by smoothly, output also > > attached), downgraded all of the ovirt packages back to 3.1.0-4 > > (because engine-upgrade didn´t think there was any updating to act > > upon otherwise), then updated ovirt-engine-setup to 3.2.2, lastly ran > > engine-upgrade. That made it pass the database upgrade, yeay! But! > > Now it stopped at doing the CA instead... Log is attached. > > > > What I find strange is the last line of output from the upgrade.sh: > > ... > > Refreshing materialized views... > > Done. > > /usr/share/ovirt-engine/dbscripts > > > > Where the last lines of upgrade.sh are like: > > ... > > run_upgrade_files > > > > ret=$? > > printf "Done.\n" > > exit $ret > > > > And I looked through run_upgrade_files and couldn´t figure out why > > that function would exit with "/usr/share/ovirt-engine/dbscripts"? No > > that doesn´t quite add up. Something just doesn´t smell right but I > > haven´t figured it out what it is yet, > > > > I think it is the output from another script that runs the upgrade.sh > script. There's a pushd/popd action used in sh scripts to change > working folder and then get back to the original one. I think that this > is what you see here. > > > > > About the second error, with handling the CA, it seems like it´s > > having trouble connecting to the database after it´s upgrade, but > > since the upgrade itself went by OK, I did engine-cleanup, > > engine-setup, stopped engine, restored the database and started > > engine again, and it worked. Which should point more to something > > like a configuration being missed, or improperly handled at the > > upgrade that makes engine-config fail to connect. > > Could be; but the fact that reimport of the DB worked is a very good > sign. > > > Maybe some old configurations lying around that shouldn´t be, that > > hinders it, I don´t know. Is there anything handling configuration > > changes, like "rpmconf -a" in the upgrade process, after updating the > > rpms? > > > > No, we do not have rpmconf in ovirt. > > Now, if you have a working engine, that's good. Remember though that > you started with clean DB. When DB has entries, the upgrade.sh run may > not be as fluent as it was before. But, if it works, I guess you could > use the same strategy for upgrading the complete working environment: > > 1. Backup DB and certificates > 2. Upgrade DB in a stand-alone mode and save it aside. > 3. Install 3.2, restore the engine DB from upgraded backup. > 4. Restore certificates. > 5. Start the engine. > 6. Enjoy? > > Let me know what your status is. > > > > > > /Karli > > > > ons 2013-06-26 klockan 13:33 +0000 skrev Karli Sjöberg: > >> tis 2013-06-25 klockan 16:02 +0003 skrev Alex Lourie:  > >>> On Tue, Jun 25, 2013 at 5:03 PM, Karli Sjöberg > >>> <Karli.Sjoberg(a)slu.se&gt; > >>> wrote: > >>> > tis 2013-06-25 klockan 15:35 +0200 skrev Gianluca Cecchi: On > >>> Tue, > >>> > Jun 25, 2013 at 2:58 PM, Karli Sjöberg wrote: > >>> >  > >>> >>> > >>> >>> > >>> > Yes, I had much better success following that article, and > >>> managed > >>> > to upgrade fedora to 18, had to tune my kernel parameters a > >>> little > >>> > for the postgres upgrade to work, but then engine-upgrade fails > >>> just > >>> > as it did the last time we tried. The log is attached. Hoping to > >>> hear > >>> > back from you soon with ideas on what to try next. > >>> >  > >>> >>> > >>> >>> > >>> >>> > >>> >  > >>> >> > >>> >> > >>> > But now the error seems different from the original one in > >>> March > >>> > (if I remember correctly the original post). > >>> >> > >>> > > >>> > They are quite the same: > >>> > > >>> > Then > >>> > psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop > >>> function > >>> > uuid_nil() because extension uuid-ossp requires it > >>> > > >>> > Now > >>> > 2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = > >>> > psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop > >>> function > >>> > uuid_nil() because extension uuid-ossp requires it > >>> > > >>> >> Could it be somehow related with this rhev one bug: > >>> > https://bugzilla.redhat.com/show_bug.cgi?id=923614 > >>> >> > >>> >> > >>> > and that changing permissions for the impacted objects in db > >>> before > >>> > running upgrade could help? > >>> > >> > >> I have now tried that and it did no change in success there > >> unfortunately, so it´s probably not anything permissions related in > >> the database. > >> > >> dbmodify: > >> #!/bin/sh > >> export PGPASSFILE=/root/.pgpass > >> for tbl in `psql -U postgres -wqAt -c "select tablename from > >> pg_tables where schemaname = 'public';" engine` ; do psql -U > >> postgres -c "alter table $tbl owner to engine" engine ; done > >> for tbl in `psql -U postgres -wqAt -c "select sequence_name from > >> information_schema.sequences where sequence_schema = 'public';" > >> engine`; do psql -U postgres -c "alter table $tbl owner to engine" > >> engine ; done > >> for tbl in `psql -U postgres -wqAt -c "select table_name from > >> information_schema.views where table_schema = 'public';" engine` ; > >> do psql -U postgres -c "alter table $tbl owner to engine" engine ; > >> done > >> > >> # yum update -y ovirt-engine-setup > >> # ./dbmodify > >> # engine-upgrade > >> > >> fail > >> > >> Log is attached this time as well, it bombs out at the exact same > >> place, in the same way. > >> > >> /K > >> > >>> >> > >>> > > >>> > Very interesting, thanks for the hint! That is definitely worth > >>> > trying out. Will try that first thing tomorrow:) > >>> > >>> Hi Karli > >>> > >>> If it helps, let me know - I will add a troubleshooting section to > >>> the > >>> wiki. > >>> > >>> > > >>> > > >>> >> > >>> >> > >>> >> > >>> > BTW: is your environment directly created in 3.1 or did it come > >>> > from a further upgrade? > >>> >> > >>> > > >>> > Started with a minimal Fedora 17 install, added the oVirt-3.1 > >>> repo, > >>> > ran yum upgrade -y first, then yum install -y ovirt-engine and > >>> lastly > >>> > engine-setup. Nothing more. So it´s just an empty engine that > >>> I´m > >>> > trying to upgrade at this point. When that works, I´ll add > >>> hosts, > >>> > VMs, Templates, etc. > >>> > > >>> >> > >>> >> > >>> >> > >>> > HIH, > >>> > Gianluca > >>> > > >>> > -- > >>> > > >>> > Med Vänliga Hälsningar > >>> > > >>> ------------------------------------------------------------------------------- > >>> > Karli Sjöberg > >>> > Swedish University of Agricultural Sciences > >>> > Box 7079 (Visiting Address Kronåsvägen 8) > >>> > S-750 07 Uppsala, Sweden > >>> > Phone: +46-(0)18-67 15 66 > >>> > karli.sjoberg(a)slu.se > >>> > >>> > >> > >> -- > >> > >> Med Vänliga Hälsningar > >> ------------------------------------------------------------------------------- > >> Karli Sjöberg > >> Swedish University of Agricultural Sciences > >> Box 7079 (Visiting Address Kronåsvägen 8) > >> S-750 07 Uppsala, Sweden > >> Phone: +46-(0)18-67 15 66 > >> karli.sjoberg(a)slu.se > > > > -- > > > > Med Vänliga Hälsningar > > ------------------------------------------------------------------------------- > > Karli Sjöberg > > Swedish University of Agricultural Sciences > > Box 7079 (Visiting Address Kronåsvägen 8) > > S-750 07 Uppsala, Sweden > > Phone: +46-(0)18-67 15 66 > > karli.sjoberg(a)slu.se > > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users