[Engine-devel] Features requests for the setup/configuration utilities - feedback requested
Hi All As we are working on the configuration utilities (engine-setup, engine-upgrade and engine-cleanup), we would like to get as much community involvement as possible. As such, we'd like to hear the wishes of the community in regards with those tools. I've created a wiki page [1] where we will keep the list of feature requests. We would appreciate adding features to the list of by replying to this thread directly. Please do not bugs to that list - the bugs should be resolved in due course according to their priorities and should not affect the features that we would like to implement. Thank you. [1] http://www.ovirt.org/Features/Engine-Config-Utilities -- Alex Lourie Software Engineer in RHEVM Integration Red Hat
On Thu, 14 Mar 2013 12:12:25 +0002 Alex Lourie <alourie@redhat.com> wrote:
Hi All
As we are working on the configuration utilities (engine-setup, engine-upgrade and engine-cleanup), we would like to get as much community involvement as possible. As such, we'd like to hear the wishes of the community in regards with those tools.
1. do not think yum is everywhere, make package upgrade extensible by some subclasses (apt-get, pkg_add...) 2. usernames are not same everywhere postgres is not everywhere 3. do not make absolute symlinks, some packaging tools scream 4. do not use #!/bin/bash but #!/bin/sh, in 99,9% people are not using anything special from bash anyway jbelka
----- Original Message -----
From: "Jiri Belka" <jbelka@redhat.com> To: "Alex Lourie" <alourie@redhat.com> Cc: engine-devel@ovirt.org, Users@ovirt.org Sent: Thursday, March 14, 2013 2:52:31 PM Subject: Re: [Users] Features requests for the setup/configuration utilities - feedback requested
On Thu, 14 Mar 2013 12:12:25 +0002 Alex Lourie <alourie@redhat.com> wrote:
Hi All
As we are working on the configuration utilities (engine-setup, engine-upgrade and engine-cleanup), we would like to get as much community involvement as possible. As such, we'd like to hear the wishes of the community in regards with those tools.
1. do not think yum is everywhere, make package upgrade extensible by some subclasses (apt-get, pkg_add...)
Right.
2. usernames are not same everywhere postgres is not everywhere
Right.
3. do not make absolute symlinks, some packaging tools scream
I replied to this one, I don't fully agree, relative symlinks have their own issues, and hard to convert absolute to relative when 3rd party components are involved.
4. do not use #!/bin/bash but #!/bin/sh, in 99,9% people are not using anything special from bash anyway
This is out of scope, we will depend on bash for now... too much legacy. We can attend to that in future. I can promise that no new code will be written in bash. Thanks!
jbelka _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
----- Original Message -----
From: "Jiri Belka" <jbelka@redhat.com> To: "Alex Lourie" <alourie@redhat.com> Cc: engine-devel@ovirt.org, Users@ovirt.org Sent: Thursday, March 14, 2013 2:52:31 PM Subject: Re: [Users] Features requests for the setup/configuration utilities - feedback requested
On Thu, 14 Mar 2013 12:12:25 +0002 Alex Lourie <alourie@redhat.com> wrote:
Hi All
As we are working on the configuration utilities (engine-setup, engine-upgrade and engine-cleanup), we would like to get as much community involvement as possible. As such, we'd like to hear the wishes of the community in regards with those tools.
1. do not think yum is everywhere, make package upgrade extensible by some subclasses (apt-get, pkg_add...)
Right.
2. usernames are not same everywhere postgres is not everywhere
Right.
3. do not make absolute symlinks, some packaging tools scream
I replied to this one, I don't fully agree, relative symlinks have their own issues, and hard to convert absolute to relative when 3rd party components are involved.
4. do not use #!/bin/bash but #!/bin/sh, in 99,9% people are not using anything special from bash anyway
This is out of scope, we will depend on bash for now... too much legacy. We can attend to that in future. I can promise that no new code will be written in bash.
Thanks!
jbelka _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Wiki updated. Thanks!
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... :) jbelka
Hi Jiri On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbelka@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?
jbelka
On Thu, 14 Mar 2013 14:44:48 +0002 Alex Lourie <alourie@redhat.com> wrote:
Hi Jiri
On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbelka@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.
On 03/14/2013 04:55 PM, Jiri Belka wrote:
On Thu, 14 Mar 2013 14:44:48 +0002 Alex Lourie <alourie@redhat.com> wrote:
Hi Jiri
On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbelka@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?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Jiri Belka" <jbelka@redhat.com> Cc: engine-devel@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 <alourie@redhat.com> wrote:
Hi Jiri
On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbelka@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
On 03/15/2013 08:07 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Jiri Belka" <jbelka@redhat.com> Cc: engine-devel@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 <alourie@redhat.com> wrote:
Hi Jiri
On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbelka@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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, Users@ovirt.org, "Jiri Belka" <jbelka@redhat.com> Sent: Tuesday, March 19, 2013 11:48:51 PM Subject: Re: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested
On 03/15/2013 08:07 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Jiri Belka" <jbelka@redhat.com> Cc: engine-devel@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 <alourie@redhat.com> wrote:
Hi Jiri
On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka <jbelka@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)
Great!
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.
If we do not want to stop engine service on rpm installation, we can have some kind of notification in engine that the software was updated and a restart is required. Alon
participants (4)
-
Alex Lourie -
Alon Bar-Lev -
Itamar Heim -
Jiri Belka