[Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested

[Itamar Heim]

On 03/15/2013 08:07 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Jiri Belka" <jbelka at redhat.com>
>> Cc: engine-devel at ovirt.org, Users at ovirt.org
>> Sent: Friday, March 15, 2013 1:27:32 PM
>> Subject: Re: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested
>>
>> On 03/14/2013 04:55 PM, Jiri Belka wrote:
>>> On Thu, 14 Mar 2013 14:44:48 +0002
>>> Alex Lourie <alourie at redhat.com> wrote:
>>>
>>>> Hi Jiri
>>>>
>>>> On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbelka at redhat.com>
>>>> wrote:
>>>>> I'll talk about RHEVM but it's probably related to oVirt too.
>>>>>
>>>>> As rhevm installs all deps, I'm curious why versionlock.list is
>>>>> populated after rhevm-setup and _not_dirrectly during
>>>>> installation
>>>>> (maybe because you would need to hardcode versions into rhevm
>>>>> package?). It took me tens of minutes to figure out why is
>>>>> upgrade
>>>>> working differently now, just because I did _NOT_ do rhevm-setup
>>>>> after
>>>>> clean install because I was thinking I know what files are
>>>>> important
>>>>> and was restoring them from a tarball.
>>>>>
>>>>> I think running rhevm-setup if you just want to restore is
>>>>> stupid. If
>>>>> we would know 100% which files are involved, just install,
>>>>> restore
>>>>> from
>>>>> backup, restore DB should be sufficient, without loosing time
>>>>> with
>>>>> rhevm-setup which just writes there and here... :)
>>>>>
>>>>
>>>> I don't really follow you here. What are you restoring with
>>>> rhevm-setup?
>>>
>>> My previous (wrong) procedure to restore old version was:
>>>
>>> rhevm-cleanup, yum remove rhevm\*, rm -rf $dirs, yum install
>>> rhevm\*,
>>> tar xvzpf /backup.tgz, ./restore.sh for DB...
>>>
>>> which was not fully correct as I haven't
>>> known /etc/yum/plugin.d/versionlock.list is touched by rhevm-setup
>>> as
>>> well and thus yum was working very strange during next normal
>>> upgrade.
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>> moran/ofer - i remember some discussions on moving from version lock
>> to
>> a yum plugin. i.e., yum will not update the packages if not getting
>> some
>> parameter from engine-upgrade (but will show updates exist), but they
>> will behave normally other than that?
>
> We cannot mention yum specific features in setup context any more... this is part of the mission.
>
> We should reconsider the locking of version - no product uses this.
>
> After upgrade of packages, product should either know not to start or upgrade the database when restarted, or better know to work with older schema.
>
> The version lock should be removed as soon as possible.
>
> Alon
>

I think we can remove the version lock (after relevant preparations/changes)
I still think a yum plugin to not yum update rpms which are part of the 
engine without a special script/yum paramter invoking them) is 
worthwhile, since i don't like the concept of someone running yum 
update, only to find out the upgrade had an issue a week later when 
restarting the service.