Re: [Users] Migrating engine-setup to otopi
Hi all, The patch introducing the new implementation is now under review: http://gerrit.ovirt.org/14612 Il 14/03/2013 11:13, Alex Lourie ha scritto: Hi All Recent development of the otopi [1] framework allows us to migrate the engine-setup, upgrade and cleanup (and potentially other) utilities to implementation as an otopi plugin. Potential benefits of such a move are: 1. Be able to port engine to other distributions. 2. Be able to install engine in a development mode. 3. Be able to customize installation easily. 4. Share installation of components (reports, dwh). 5. Modular implementation, reduce maintenance costs. 6. Code reuse of installer code for multiple purposes (host-deploy, enigne-setup). Currently we are in the process of creating a 'setup' plugin for the otopi, and the progress can be monitored at [2]. The current roadmap for the feature is as follows: 1. Recreate the configuration utilities as plugins in otopi. 2. Support side-by side installation using both the old and the new utilities. 3. Switch to the new utility when the confidence that it is on-par with an old one is high. Our goal is to have the new utilities ready for 3.3 release (at least for the step 2 in the roadmap). We'd like to hear as much feedback as possible, so we could address it as soon as possible. Thanks! [1] http://gerrit.ovirt.org/#/q/project:otopi,n,z [2] http://www.ovirt.org/Features/Otopi_Infra_Migration ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Migrating engine-setup to otopi
Hi All Recent development of the otopi [1] framework allows us to migrate the engine-setup, upgrade and cleanup (and potentially other) utilities to implementation as an otopi plugin. Potential benefits of such a move are: 1. Be able to port engine to other distributions. 2. Be able to install engine in a development mode. 3. Be able to customize installation easily. 4. Share installation of components (reports, dwh). 5. Modular implementation, reduce maintenance costs. 6. Code reuse of installer code for multiple purposes (host-deploy, enigne-setup). Currently we are in the process of creating a 'setup' plugin for the otopi, and the progress can be monitored at [2]. The current roadmap for the feature is as follows: 1. Recreate the configuration utilities as plugins in otopi. 2. Support side-by side installation using both the old and the new utilities. 3. Switch to the new utility when the confidence that it is on-par with an old one is high. Our goal is to have the new utilities ready for 3.3 release (at least for the step 2 in the roadmap). We'd like to hear as much feedback as possible, so we could address it as soon as possible. Thanks! [1] http://gerrit.ovirt.org/#/q/project:otopi,n,z [2] http://www.ovirt.org/Features/Otopi_Infra_Migration ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Migrating engine-setup to otopi
On Thu, 14 Mar 2013 06:13:39 -0400 (EDT) Alex Lourie alou...@redhat.com wrote: Hi All Recent development of the otopi [1] framework allows us to migrate the engine-setup, upgrade and cleanup (and potentially other) utilities to implementation as an otopi plugin. Potential benefits of such a move are: 1. Be able to port engine to other distributions. Really? Beside this topic I see hardcoded usernames in scripts... http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified Anyway, everything what is not RPM/YUM specific and more portable is good way... jbelka ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Migrating engine-setup to otopi
- Original Message - From: Jiri Belka jbe...@redhat.com To: Alex Lourie alou...@redhat.com Cc: engine-de...@ovirt.org, users@ovirt.org Sent: Thursday, March 14, 2013 12:38:46 PM Subject: Re: [Users] Migrating engine-setup to otopi On Thu, 14 Mar 2013 06:13:39 -0400 (EDT) Alex Lourie alou...@redhat.com wrote: Hi All Recent development of the otopi [1] framework allows us to migrate the engine-setup, upgrade and cleanup (and potentially other) utilities to implementation as an otopi plugin. Potential benefits of such a move are: 1. Be able to port engine to other distributions. Really? Beside this topic I see hardcoded usernames in scripts... This is going away soon. http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified Anyway, everything what is not RPM/YUM specific and more portable is good way... jbelka ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Migrating engine-setup to otopi
Hi Jiri - Original Message - From: Jiri Belka jbe...@redhat.com To: Alex Lourie alou...@redhat.com Cc: engine-de...@ovirt.org, users@ovirt.org Sent: Thursday, March 14, 2013 12:38:46 PM Subject: Re: [Users] Migrating engine-setup to otopi On Thu, 14 Mar 2013 06:13:39 -0400 (EDT) Alex Lourie alou...@redhat.com wrote: Hi All Recent development of the otopi [1] framework allows us to migrate the engine-setup, upgrade and cleanup (and potentially other) utilities to implementation as an otopi plugin. Potential benefits of such a move are: 1. Be able to port engine to other distributions. Really? Beside this topic I see hardcoded usernames in scripts... http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified These usernames are not hard-coded. There are default values present which are kept for local installations, but with remote DB setup the user is prompted to provide a username of her/his own. Anyway, everything what is not RPM/YUM specific and more portable is good way... Thanks! jbelka -- Best regards, Alex Lourie Software Developer in Integration Red Hat ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Migrating engine-setup to otopi
On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) Alex Lourie alou...@redhat.com wrote: 1. Be able to port engine to other distributions. Really? Beside this topic I see hardcoded usernames in scripts... http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified These usernames are not hard-coded. There are default values present which are kept for local installations, but with remote DB setup the user is prompted to provide a username of her/his own. Not everywhere are postgresql dirs owned by postgres, on some BSDs it is _postgresql. jbelka ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Migrating engine-setup to otopi
- Original Message - From: Jiri Belka jbe...@redhat.com To: Alex Lourie alou...@redhat.com Cc: engine-de...@ovirt.org, users@ovirt.org Sent: Thursday, March 14, 2013 1:47:12 PM Subject: Re: [Users] Migrating engine-setup to otopi On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) Alex Lourie alou...@redhat.com wrote: 1. Be able to port engine to other distributions. Really? Beside this topic I see hardcoded usernames in scripts... http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified These usernames are not hard-coded. There are default values present which are kept for local installations, but with remote DB setup the user is prompted to provide a username of her/his own. Not everywhere are postgresql dirs owned by postgres, on some BSDs it is _postgresql. Right, as I said this is going away. I am porting this first to Gentoo, which is the most complex, then I will be able to provide debian based. For the postgres issue, I am against assuming local database and the configuration of the database it-self (hba, etc). Like in other products, the dba will create a user and a database with the user as an owner and provide us the user/password and database name, this method does not require privileged database user for product installation and working locally or remotely, and is portable. We will keep the functionality of system provisioning as an optional component exists in some distribution. Regards, Alon Bar-Lev ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
