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:
(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:
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?
(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.
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...
(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.
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?
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.
Done https://access.redhat.com/solutions/2131931
I would still ask for a message in the engine setup which would point the customers to this KCS.
(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.
(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.