----- Original Message -----
> From: "Itamar Heim" <[email protected]>
> To: "Alon Bar-Lev" <[email protected]>
> Cc: "Jiri Belka" <[email protected]>, [email protected], [email protected]
> Sent: Friday, March 15, 2013 1:24:25 PM
> Subject: Re: [Engine-devel] [Users] Migrating engine-setup to otopi
>
> On 03/14/2013 01:52 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Jiri Belka" <[email protected]>
> >> To: "Alex Lourie" <[email protected]>
> >> Cc: [email protected], [email protected]
> >> 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 <[email protected]> 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.
>
> actually, I'm against assuming we need a dba for a local install.
> we need to keep deployment easy, not assume user should worry about
> the
> db at all (other than providing the password for it, since it is
> needed
> later).
>
> can you pleas explain the concern, and the suggested solution on how
> it
> will look to run engine-setup/engine-upgrade in your approach?
Let's start from the end... there will be no change (accept of maybe be one/two
more prompts during installation) at rhel/centos/fedora.
Now...
People who wrote the current installation confused between host provisioning
and database interaction.
Another confusion out there is the wrong assumption that ovirt-engine owns the
system it installed on, and can perform changes to shared system components
such as apache and postgres.
Both of these should not leak into other distributions as we port, oh well, as
much as we can, in our current state.
Host provisioning:
1. Check if postgres is installed on host.
2. Check if postgres already initialized its database and optionally perform
initdb.
3. Start postgres service.
4. Mark postgres service to start at boot.
5. Open network access to postgres.
6. Set network authentication (pg_hba).
7. Set the dba (postgres) user password.
8. Create user for engine database.
9. Create database for engine.
Database interaction:
1. Accept application user/password.
Either:
a2. Create schema.
a3. Import data.
Or:
b2: Upgrade database.
Now, let's assume we are going to support oracle or db2, will we do the host
provisioning as part of our setup? well, we can provide a script to do that,
but most likely the dba already know how to install and configure his database
to be ready for the database interaction phase.
Another issue is that in case of remote database, we are unable to perform the
host provisioning anyway, making the local vs remote installation procedure
different, so installation documentation becomes even more complex.
And of course there is the issue of permissions, we cannot assume the user that
is installing ovirt-engine have dba permissions to the database, especially if
the database is remote.
Well behaved database application will skip the host provisioning and perform
the database interaction only. While the user will configure database and
create the database for the product.
We are going to be well behaved, this is mandatory for porting.
There can be host provisioning plugin to optionally perform the provisioning
phase, this is distribution dependent plugin, which will run only on supported
distributions and the database is installed locally. Currently we will support
the currently supported distributions, I am not sure it is wroth the effort to
port this module.
Example for user visible change if provisioning module is enabled:
---
Database host [localhost]: localhost
You have selected local database, setup can configure the database
for ovirt-engine use, this includes system configuration and database
creation.
Do you wish installer to configure database, or you prefer to do so manually
(configure, manual) [configure]: manual
Please configure database to accept network password connections at
pg_hba.conf:
host all all 127.0.0.1/32 password
host all all ::1/128 password
Then create user and database, example:
create user engine password 'engine';
create database engine owner engine;
Database user:
Database user password:
Database name:
---
Of course the provisioning module can be enforced to "configure", skipping this
question, this can be done by installing configuration file as part of the
branding.
Comments?
Alon
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
