[ovirt-users] Fail to upgrade to 4.1 from 4.0

[Yedidyah Bar David]

On Fri, Sep 16, 2016 at 2:53 PM, Martin Perina <mperina at redhat.com> wrote:
> Hi,
>
> I'm glad that you new attempt to upgrade 3.6 to 4.0 were successfull and 4.0
> is now working OK for you.
>
> More answers to questions inline:
>
> On Thu, Sep 15, 2016 at 9:50 PM, Marcin M. Jessa <lists at yazzy.org> wrote:
>>
>> On 15/09/2016 12:58, Martin Perina wrote:
>>>
>>> So something went wrong on that upgrade from 3.6 to 4.0 and  it was not
>>> a good idea to do another upgrade when previous one went wrong.
>>
>>
>> The upgrade process went fine. The upgrade script never showed any errors.
>
>
> Hmm, that's strange, because from latest setup log you sent me I'd say that
> 3.6 to 4.0 upgrade was not successful. But to confirm that I'd need to
> investigate all setup logs from 3.6 upgrade ..
>
>>
>>
>>> Anyway to confirm that could you please share with us also upgrade log
>>> between
>>> 3.6 and 4.0? Also how did you do the upgrade (especially what OS have
>>> you used on 3.6 and if upgrade was done using engine-backup or in-place)?
>>
>>
>> I backed up the installation but then I ran in-place upgrade. I was told
>> on the irc I don't need to restore from backups when I'm already on CentOS
>> 7. Actually failing to restore from backup brought me to the IRC in the
>> first place.
>
>
> Yes, when doing in-place upgrade you don't need to do restore, that's why I
> asked how you performed your upgrade
>
>>
>>
>> I'm on CentOS Linux release 7.2.1511 (Core)
>> Upgrading I followed exactly the same doc you pointed to below.
>> Except when updating to 4.1 failed, I uninstalled everything that had to
>> do with ovirt and installed the 4.0 release.
>>
>>> More details about upgrade options from 3.6 to 4.0 can be found at:
>>> http://www.ovirt.org/documentation/migration-engine-3.6-to-4.0/
>>
>> Because of that doc I installed 4.1 instead of the stable 4.0 ...
>
>
> Yes, that's a shame for our project to have outdated upgrade doc several
> month after GA release :-(
> Thanks for pointing this out, here's PR which fixes wrong repository URL:
>
> https://github.com/oVirt/ovirt-site/pull/467
>
>>
>>
>>> So from current log I can see that upgrade from 3.6 to 4.0 was not
>>> successfully finished and that's why you had issues during upgrade on
>>> master.
>>
>> Out of curiousity, where did you see that 3.6 to 4.0 update failed?
>
>
> In your setup log I can see following:
>
>   Dropping materialized views...
>   Skipping upgrade script
> /usr/share/ovirt-engine/dbscripts/upgrade/03_06_0000_set_version.sql, its
> version 03060000 is <= current version 04000860
>   Skipping upgrade script
> /usr/share/ovirt-engine/dbscripts/upgrade/03_06_0010_update_haswell_vds_to_new_name.sql,
> its version 03060010 is <= current version 04000860
>
>
> If 3.6 was properly upgraded to 4.0, you wouldn't see any records like this,
> you'd see applying only 4.1 upgrade scripts, for example:

Are you sure about this? Please note that the above lines are a result of a
rather-recent change [1], before it they never appeared in the log (but similar
ones did appear due to other reasons).

[1] https://gerrit.ovirt.org/59441

>
>   Dropping materialized views...
>   Running upgrade sql script
> '/usr/share/ovirt-engine/share/ovirt-engine/dbscripts/upgrade/04_01_0010_add_mac_pool_id_to_vds_group.sql'...
>   Running upgrade sql script
> '/usr/share/ovirt-engine/share/ovirt-engine/dbscripts/upgrade/04_01_0020_empty_current_cd_to_null.sql'...
>
>
>
>>
>>> Personaly I'd recommend you to get back into 3.6 (either by restoring
>>> from backup (if you performed in-place upgrade) or shutting down new
>>> host and starte pervious 3.6 host (if you performed upgrade using
>>> engine-backup) and do upgrade to 4.0 again. And if upgrade from 3.6 to
>>> 4.0 is not successful, please share the logs again.
>>
>>
>> I'll try from scratch again, uninstalling everything, installing 3.6,
>> restoring backups and upgrading to 4.0
>>
>> I don't want to be a party popper but to be honest you need a testing
>> engineer. The upgrade process is way too fragile and breaks too easily...
>>
>> --
>>
>> Marcin M. Jessa
>
>



-- 
Didi