Description of problem: The Performance & Scale Tuning Guide at https://access.redhat.com/articles/2626101 provides very useful recommendations on how to tune Satellite 6.2. Unfortunately several of the suggested customisations are wiped by the installer, for example when upgrading to a newer release. The Performance & Scale Tuning Guide should state how to add the suggested customisations to file /etc/foreman-installer/custom-hiera.yaml so the customisations are preserved across upgrades. Version-Release number of selected component (if applicable): ma-red-hat-satelllite-62-performance-brief-f5544-201703-en.pdf https://access.redhat.com/articles/2626101 How reproducible: N/A Steps to Reproduce: 1. Apply the customisations in the guide. 2. Run satellite-installer --upgrade 3. Check for the previously applied customisations Actual results: Most customisations in /etc/httpd/* are reverted back to the defaults after the installer has ran. Expected results: Customisations are preserved across executions of the installer. The performance and scaling tuning guide provides details on how to apply the customisations in file /etc/foreman-installer/custom-hiera.yaml so the customisations survive executions of the installer (e.g. upgrades). Additional info: https://github.com/redhat-performance/satellite-tune/issues/23 The following customisations from the Guide can already be persisted in /etc/foreman-installer/custom-hiera.yaml : - File /etc/httpd/conf.d/05-foreman-ssl.d/katello.conf "katello::max_keep_alive" - File /etc/default/pulp_workers "pulp::num_workers" "pulp::max_tasks_per_child" - File /etc/httpd/conf.d/05-foreman-ssl.d/katello.conf "apache::mod::passenger::passenger_max_pool_size" "apache::mod::passenger::passenger_max_instances_per_app" "apache::mod::passenger::passenger_max_request_queue_size" "apache::mod::passenger::passenger_stat_throttle_rate" "apache::mod::passenger::passenger_max_requests" The following customisations from the Guide don't seem to have a way of being persisted across upgrades in /etc/foreman-installer/custom-hiera.yaml : - File /etc/httpd/conf.d/05-foreman-ssl.conf PassengerMaxPoolSize PassengerMaxRequestQueueSize PassengerStatThrottleRate PassengerMaxRequests - File /etc/httpd/conf.d/25-puppet.conf PassengerMinInstances PassengerStartTimeout PassengerMaxPreloaderIdleTime PassengerMaxRequests PassengerPreStart - File /var/lib/pgsql/data/postgresql.conf max_connections
Installer certainly isn't the right category, and if Performance isn't the right one I don't know that this belongs in Bugzilla. It looks like the performance team keeps track of the changes to the document on GitHub. The authors of the document should take care of the necessary changes to convert to using custom-hiera.yaml, and in cases where something can't be addressed please open an individual BZ. @Pradeep Do you have a bugzilla category you want this moved to or can I close this BZ and leave you to address this upstream on GitHub?
Its nothing to do with performance. Its by design, config files are reverted after upgrade. 3 options here 1) I am pushing tunings here. I have plans to take backup before upgrade and apply again. https://github.com/redhat-performance/satellite-tune 2) Update puppet hiera 3) fix this bz.
This is loosely related to performance since the changes that customers apply are meant to improve performance. This is also related to the installer since the installer is what wipes the performance related settings. Option 1) sounds good to me as long as you don't need to re-run satellite-tune after each upgrade. While satellite-tune is a nice addition for those who don't even have time to read the perf & scale tuning guide, if the settings applied by satellite-tune are still wiped by the satellite installer then the problem remains. Option 2) seems sensible: provide a way for any tuning settings (whether applied manually or by satellite-tune) to survive Satellite upgrades. Please re-assign the component accordingly if you think this is the way to go.
It's not a bug the installer ensures the system is in the state we expect it to be in, it solves far more problems than it causes. We now provide a mechanism to persist settings via Hiera, so that's really the preferred approach from me. @Julio, I'd suggest posting the work you did to convert it to custom-hiera.yaml to the GitHub issue, so they have something to work from. If you encounter specific tuning that can't be set by Hiera, please open a specific and individual BZ for that and I can help you get that into the installer. I agree the tuning document should only be a set of changes to place in custom-hiera.yaml so users can stop wrestling with Puppet. But as far as this BZ, I don't see what's actionable from the Installer team. We don't maintain the performance document. If that belongs eleswhere in BZ please reopen it and move it, but it looks like it's all being handled through that GitHub issue linked in comment #0.
@Julio: For these settings: PassengerMaxPoolSize PassengerMaxRequestQueueSize PassengerStatThrottleRate You can change the global configuration, isn't that sufficient or does it need t be per-app? Incidentally, once customers move to Puppet 4 (in 6.4 it'll be mandatory), there will only be one passenger app anyway. Postgresql is harder because of how that puppet class manages configuration. I started a thread about it upstream to get some feedback: https://groups.google.com/forum/#!topic/foreman-dev/mKELbDvo-TQ Feel free to weigh in. There are several bZ's about postgresql config, https://bugzilla.redhat.com/show_bug.cgi?id=1440879 is one FYI, I'll have to find the others and see if they can't be combined into one. If you're aware of others that don't have BZ's feel free to open then and I can make the changes upstream. Most of the time it's fairly quick/simply changes.
I've created bugs 1449697 and 1449707 to report the settings of passenger and postgresql that can't yet be persisted in custom-hiera.yaml . (In reply to Stephen Benjamin from comment #8) > @Julio: > > For these settings: > > PassengerMaxPoolSize > PassengerMaxRequestQueueSize > PassengerStatThrottleRate > > You can change the global configuration, isn't that sufficient or does it > need t be per-app? I'm unsure, but if that's the case then the tuning guide should be updated accordingly. If we release a guide suggesting customers to customise some satellite settings, these settings should survive executions of the installer.
Some of the tunings have been applied in custom-hiera by saurabh https://github.com/redhat-performance/satellite-tune/commit/bc6d33c2afea28ce6ec149f746aa7e42a804fae2
*** Bug 1472585 has been marked as a duplicate of this bug. ***
State of things with 6.3 ======================== /etc/httpd/conf.modules.d/prefork.conf ServerLimit StartServers apache::mod::prefork::serverlimit: 512 apache::mod::prefork::startservers: 10 ------ /etc/httpd/conf.d/05-foreman.conf /etc/httpd/conf.d/05-foreman-ssl.conf KeepAlive KeepAliveTimeout MaxKeepAliveRequests foreman::keepalive: true foreman::max_keepalive_requests: 0 foreman::keepalive_timeout: 5 These are also available using the installer, see `satellite-installer --full-help` ------ /etc/systemd/system/httpd.service.d/limits.conf Doesn't conflict with the installer. ------ 5.2 Passenger PassengerMaxPoolSize PassengerMaxRequestQueueSize PassengerStatThrottleRate apache::mod::passenger::passenger_max_pool_size: <N> apache::mod::passenger::passenger_max_request_queue_size: <N> apache::mod::passenger::passenger_stat_throttle_rate: <N> ------ 5.4 Pulp Workers /etc/default/pulp_workers PULP_CONCURRENCY PULP_MAX_TASKS_PER_CHILD katello::num_pulp_workers: <N> katello::max_tasks_per_pulp_worker: <N> These are also available using the installer, see `satellite-installer --full-help` ------ 5.7 dynFlow /etc/sysconfig/foreman-tasks Doesn't conflict with the installer. ------ 5.8 PostgeSQL /var/lib/pgsql/data/postgresql.conf Not possible today, requires https://github.com/puppetlabs/puppetlabs-postgresql/pull/950 and maybe other changes. ------ 5.13.3 5.13.4 Are also not possible today, see https://bugzilla.redhat.com/show_bug.cgi?id=1443138 & https://bugzilla.redhat.com/show_bug.cgi?id=1366323
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2927