At the moment the installation guide suggests (in section 3.2): "You can use the setup script to install and configure a local database server or use an existing remote database server.", so if the database is local 'rhevm-setup' will configure it as per RHEV-M requirements but if the database is remote such task and responsibility is left to the customer. Customer expects 'rhevm-setup' (or a separate installer) to be able to install and configure a PostgreSQL database in a separate host as per RHEV-M requirements in the same way as if the database was installed locally on RHEV-M host, including: - settings such as the maximum number of database connections allowed - authentication settings in pg_hba.conf - listen addresses - any other setting that RHEV requires to be customised (e.g. shared_buffers, etc). - SSL connectivity. - Character set. - Users and ownerships. ... It should cover, at least, the manual steps described in "3.7. Preparing a Postgres Database Server for use with Red Hat Enterprise Virtualization Manager" at [1]. See Satellite's example at "2.3.2. Managed Database Requirements" in [2]. [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Installation_Guide/Preparing_a_Postgres_Database_Server_for_use_with_Red_Hat_Enterprise_Virtualization_Manager.html [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Satellite/5.6/html/Installation_Guide/sect-Installation_Guide-Managed_Database_Requirements.html Currently a remote PostgreSQL database must be manually installed and configured. This is error prone since configuring RHEV expected settings in database such as number of connections, checking kernel.shmmax value, etc. (see 3. above) is left to users who might miss some of the required changes leading to support cases being raised once they hit problems. Expectations are same installation efforts for local and remote databases.
Basically what you expect is ovirt setup to be a full blown provisioning system, that is capable of ssh to remote system and provision the remote system as it wishes, which may conflict with the settings already exists on that system, or other applications that use the same server. If we go further, you expect any database enabled application during setup to do the same, duplicating this logic to virtually all applications in the world. What we provide is more than most applications, and I do think it is incorrect as well -- if database is local (default) engine-setup knows to provision the local machine to have database usable for application. If administrator/dba wishes non default settings, due to his own reasons, he should follow simple steps to establish database usability, at dedicated server or shared server.
Max connections can be validated during setup, good for local and remote settings. select setting from pg_settings where name='max_connections'; I will open a separate bug for this validation to happen.