Bug 1293851 - [engine-setup] Failed to execute stage 'Environment customization': Reports requires max_connections to be at least 150.
[engine-setup] Failed to execute stage 'Environment customization': Reports r...
Status: CLOSED DEFERRED
Product: ovirt-engine
Classification: oVirt
Component: Setup.Engine (Show other bugs)
3.6.1.3
Unspecified Unspecified
unspecified Severity high (vote)
: ovirt-3.6.3
: ---
Assigned To: Yedidyah Bar David
Pavel Stehlik
integration
:
Depends On:
Blocks: RHEV3.6Upgrade
  Show dependency treegraph
 
Reported: 2015-12-23 04:32 EST by Jiri Belka
Modified: 2016-01-20 09:18 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-20 09:18:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Integration
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
gklein: ovirt‑3.6.z?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Jiri Belka 2015-12-23 04:32:49 EST
Description of problem:

During upgrade from 3.5.x to 3.6-beta, engine-setup fails because of low max_connections configured in postgresql.

IMO engine-setup should try to fix it if the DB is local (edit, propose restart?) or there should be a KB/doc for this issue.

~~~
          --== DATABASE CONFIGURATION ==--

[ ERROR ] Failed to execute stage 'Environment customization': Reports requires max_connections to be at least 150. Please fix max_connections before you continue.
[ INFO  ] Stage: Clean up
          Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20151222124149-r5l7xp.log
          [ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20151222124229-setup.conf'
          [ INFO  ] Stage: Pre-termination
          [ INFO  ] Stage: Termination
~~~

perl -i.orig -pe 's/^(max_connections).*/$1 = 150/;' /var/lib/pgsql/data/postgresql.conf
/etc/init.d/postgresql restart

Version-Release number of selected component (if applicable):
rhevm-setup-3.6.1.3-0.1.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. have < 150 max_connections in postgresl (i had 3.5.x rhevm env)
2. engine-setup to upgrade to 3.6.x
3.

Actual results:
engine-setup fails

Expected results:
either if db is local there should be a try to fix the issue or info about kb/doc ?

Additional info:
Comment 1 Yedidyah Bar David 2015-12-23 05:14:18 EST
(In reply to Jiri Belka from comment #0)
> Description of problem:
> 
> During upgrade from 3.5.x to 3.6-beta, engine-setup fails because of low
> max_connections configured in postgresql.

engine-setup automatically configures that for local/auto provisioning to 150 since at least 3.3.

What is the original version of the reported setup?

engine-setup now also verifies that also for manual/remove provisioning and for upgrades, see bug 1077267.

> 
> IMO engine-setup should try to fix it if the DB is local (edit, propose
> restart?)

If that's what you want, please open a new bug (or change current) as an RFE. Not sure it needs high priority, as the workaround (just fixing manually) is trivial.

Generally speaking, we do not touch pg conf on upgrades.

> or there should be a KB/doc for this issue.

Searching the KB I can find a few mentions of this, e.g. [1].

I agree it should also be mentioned in the main docs, e.g. in [2]. Please open a doc bug for that.

[1] https://access.redhat.com/solutions/720053
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6-Beta/html/Installation_Guide/appe-Preparing_a_Remote_PostgreSQL_Database_for_Use_with_the_Red_Hat_Enterprise_Virtualization_Manager.html

> 
> ~~~
>           --== DATABASE CONFIGURATION ==--
> 
> [ ERROR ] Failed to execute stage 'Environment customization': Reports
> requires max_connections to be at least 150. Please fix max_connections
> before you continue.
> [ INFO  ] Stage: Clean up
>           Log file is located at
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20151222124149-r5l7xp.log
>           [ INFO  ] Generating answer file
> '/var/lib/ovirt-engine/setup/answers/20151222124229-setup.conf'
>           [ INFO  ] Stage: Pre-termination
>           [ INFO  ] Stage: Termination
> ~~~
> 
> perl -i.orig -pe 's/^(max_connections).*/$1 = 150/;'
> /var/lib/pgsql/data/postgresql.conf
> /etc/init.d/postgresql restart
> 
> Version-Release number of selected component (if applicable):
> rhevm-setup-3.6.1.3-0.1.el6.noarch
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. have < 150 max_connections in postgresl (i had 3.5.x rhevm env)
> 2. engine-setup to upgrade to 3.6.x
> 3.
> 
> Actual results:
> engine-setup fails
> 
> Expected results:
> either if db is local there should be a try to fix the issue or info about
> kb/doc ?
> 
> Additional info:
Comment 3 Pavel Stehlik 2015-12-23 08:35:13 EST
Please note - the reason this BZ was opened is because it is a bug. It's default environment, why should user change anything by hands? Are we asking him to change in DB version of engine? Are we asking him to change pg_hba.conf to add another user for reports/dwh?? So why we should ask him for changing number of connection then?
The less we can do is RN/KB, but definitely NO notabug!
Why to open new bug on changing that file automatically? This is THE bug, why to have another one?
Comment 4 Yedidyah Bar David 2015-12-23 08:46:28 EST
(In reply to Pavel Stehlik from comment #3)
> Please note - the reason this BZ was opened is because it is a bug.

It's working as intended/documented (in bugzilla at least).

> It's
> default environment,

There is needinfo about that, still no reply.

I guess (didn't check) it was the default of <=3.2, perhaps a bit older.

It's not the default for new setups of at least >=3.3.

> why should user change anything by hands?

I didn't say user should.

We can definitely do that for the user.

That's an RFE.

Everything has costs.

Costs include the possibility that our code will break other stuff we didn't think about while we edit conf and restart pg.

> Are we asking
> him to change in DB version of engine? Are we asking him to change
> pg_hba.conf to add another user for reports/dwh??

If needed, yes.

We have docs for that.

> So why we should ask him
> for changing number of connection then?
> The less we can do is RN/KB, but definitely NO notabug!
> Why to open new bug on changing that file automatically? This is THE bug,
> why to have another one?

I said:
> please open a new bug (or change current) as an RFE

To clarify:
1. IMO it's not a bug, but an RFE.
2. if we want doc changes, they should be tracked by another bz.
Comment 5 Yedidyah Bar David 2015-12-23 08:51:24 EST
If I may, the _bug_ is that we didn't do this check while still changing the conf for new setups. It meant that users that upgraded from older versions and/or used remote DBs suffered real, hard-to-debug problems, resulting from not enough connections.

These users will now, instead, get a simple message during engine-setup, and prevent themselves from having to go through such problems in the unexpected future.

I just hope that 150 is enough...
Comment 6 Jiri Belka 2015-12-23 10:15:15 EST
(In reply to Yedidyah Bar David from comment #1)
> (In reply to Jiri Belka from comment #0)
> > Description of problem:
> > 
> > During upgrade from 3.5.x to 3.6-beta, engine-setup fails because of low
> > max_connections configured in postgresql.
> 
> engine-setup automatically configures that for local/auto provisioning to
> 150 since at least 3.3.
> 
> What is the original version of the reported setup?

IIRC this setup has the DB config from ancient times, maybe 3.0 ? pstehlik@ will know exact original version for sure. We once migrated this old setup (backup -> restore) to HE env.
Comment 7 Roman Hodain 2016-01-20 05:27:23 EST
This looks like this will be rather a rare issue, but we cannot expect the customers to know how to change the parameters. I am OK with asking the customers to do so manually, but either provide the steps how to do so or provide a link to a DOC or KCS when reporting the error. Something like:

[ ERROR ] Failed to execute stage 'Environment customization': Reports requires max_connections to be at least 150. Please fix max_connections before you continue. Please follow this KCS for further information:

     https://.....

Would that be OK?
Comment 8 Yaniv Lavi (Dary) 2016-01-20 07:41:03 EST
We should write up a kbase for users looking for fix for this.
Roman\Didi, can you work on a kbase for this?

Please do not link in the setup code.
Comment 9 Roman Hodain 2016-01-20 07:42:48 EST
Done

https://access.redhat.com/solutions/2131931
Comment 10 Roman Hodain 2016-01-20 07:43:44 EST
I would still ask for a message in the engine setup which would point the customers to this KCS.
Comment 11 Yedidyah Bar David 2016-01-20 07:53:57 EST
(In reply to Roman Hodain from comment #9)
> Done
> 
> https://access.redhat.com/solutions/2131931

Please note that despite the subject of this bug, IIRC it's not specific to Reports - all DBs have the same requirement of 150 connections.

Also see comment 1 - you already have other similar articles.

(In reply to Roman Hodain from comment #10)
> I would still ask for a message in the engine setup which would point the
> customers to this KCS.

I'll let Yaniv decide about this, just noting that we currently do not have a system to easily replace upstream links with downstream ones. We should probably have one, if we intend to have more of these. So far happened once in setup code, see bug 1255808.
Comment 13 Yaniv Lavi (Dary) 2016-01-20 09:18:32 EST
(In reply to Roman Hodain from comment #10)
> I would still ask for a message in the engine setup which would point the
> customers to this KCS.

I don't think it is correct to make the setup in links list.
A user can look up the error and find solution. This is also a very rare case.

Note You need to log in before you can comment on or make changes to this bug.