On 03/15/2013 08:07 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Jiri Belka" <jbe...@redhat.com>
Cc: engine-de...@ovirt.org, Users@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 <alou...@redhat.com> wrote:
Hi Jiri
On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbe...@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@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.
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
