Description of problem: Our own documentation tells customer to tune the qpid component of Satellite 6 to support larger deployments. See [1] Running either katello-installer or capsule-installer as part of a normal upgrade will remove any tuning which has been done for larger deployments, and will revert /etc/qpid/qpidd.conf to a simple config for a small deployment Version-Release number of selected component (if applicable): 6.1.3 How reproducible: 100% Steps to Reproduce: 1. Edit /etc/qpid/qpidd.conf, set `max-connections=2500` 2. Run katello-installer or capsule-installer --upgrade 3. Actual results: View /etc/qpid/qpidd.conf, note that max-connections setting is gone. Expected results: qpid tuning which is done according to our documentation to support a larger deployment should be maintained. Additional info: [1] - https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.1/html/Installation_Guide/sect-Red_Hat_Satellite-Installation_Guide-Prerequisites.html#sect-Red_Hat_Satellite-Installation_Guide-Prerequisites-Large_deployments
This issue is wider than just qpid though. Anything that needs tuning for larger deployments will have it's config overwritten on upgrade.
Is it possibly we can implement this by adding something like the following to the installer --max-clients=<number> and then do the calculations internally, and setup qpid (and any other subsystem) that requires tuning for large number of clients automatically based on this information????
Stuart, I think that would be a nice approach; however, we'll need to investigate. It looks like the current issue is due to the installer managing the qpidd.conf via puppet; however, it doesn't currently manage the other configuration files suggested by the docs. We'd need to make sure that Satellite can manage those without clobbering any user data.
Brad, My theory was, that we can at least use the figure provided by (--max-clients) to work with puppet to configure qpid to resolve this issue. Any other items which need tuning, we can then raise new bugzilla's for but still leverage the configuration the customer has provided to the installer. Regards Stuart
I have the same problem to fix https://bugzilla.redhat.com/show_bug.cgi?id=1172556, where the upgrade removes my tuning of the REST timeout value in /etc/foreman/plugins/katello.yaml where i have to set rest_client_timeout: 3600 (default is 120).
And there are more tuning values from the tuning guide that are removed on upgrade. For example the passenger tunings of PassengerMaxPoolSize, PassengerMinInstances, etc in the following files: /etc/httpd/conf.d/passenger.conf /etc/httpd/conf.d/05-foreman-ssl.conf /etc/httpd/conf.d/25-puppet.conf
/etc/sysconfig/elasticsearch also reset to default by update
I was also bit with this during a katello-installer --upgrade. I had just resolved a qpidd issue with max-connections and then did an upgrade the next day. This wiped out my customizations. This should be noted somewhere in the release notes for upgrades with a list of possible config files that may need to be modified again after the installer is ran. Ideally this should just be fixed and not wipe customization made by the customer.
Per 6.3 planning, moving out non acked bugs to the backlog
We can add max connections to the installer as an option for now, but the tuning guide has some other notable issues you might want to file bugs for. Like this: "On Red Hat Enterprise Linux 7, add the following line to /usr/lib/systemd/system/qpidd.service at the end of the [Service] section: " You shouldn't edit units directly, use systemd drop-ins or similar.
Created redmine issue http://projects.theforeman.org/issues/16943 from this bug
Ah this is no longer an issue in 6.2. Clients connect to the dispatch router now, instead of qpid, and the 6.2 performance guide recommends increasing file limits with /etc/systemd/system/qdrouterd.service.d/limits.conf -- the installer won't overwrite these changes.