[Users] Fedora upgrading from 3.1 to 3.2

Sun Jun 30 15:29:50 UTC 2013

Hi Karli

On Wed, Jun 26, 2013 at 5:28 PM, Karli Sjöberg <Karli.Sjoberg at slu.se> 
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 at slu.se> 
>>> 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 at 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 at 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 at slu.se