Red Hat Bugzilla – Bug 1301185
[RFE] Puppet doesn't restart haproxy when certificate contents change
Last modified: 2018-06-19 10:23:32 EDT
Description of problem: This problem was raised to me as part of the testing of SSL on the undercloud. What happened was that the user misconfigured their SSL certificate initially, which caused the install to fail. They fixed the certificate and re-ran the installation but it still failed. It appears the problem was that when they fixed the certificate, they gave the new one the same name so puppet didn't recognize that the configuration had been changed and that haproxy needed to be restarted. Once that was done manually, the install with the new certificate completed successfully. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Perform undercloud install using an incorrect SSL certificate (perhaps with a CN that doesn't match the public VIP). This will fail. 2. Fix the certificate, but leave it at the same path. 3. Re-run the undercloud install. Actual results: The install will still fail until haproxy is restarted manually. Expected results: The install should succeed. Additional info: I don't know how this would work in puppet, but it seems like we need to be looking at the hash of the configured certificate file, not just the filename, when deciding whether to restart the service. A workaround is to not use the same filename for the new file, but I think we should sanely handle the case described above too.
TL;DR: this is not a bug. Long story: One of the most important features in Puppet are that catalog compilation is idempotent. Which means, you should be able to run Puppet multiple times, if no resource has changed, Puppet won't do anything but checking the actual resources. In the case of HAproxy, the module is puppetlabs-haproxy. In TripleO, we use this module to enable SSL termination by giving a parameter: tripleo::loadbalancer::service_certificate It represents a file path but does not manage the actual file. Which means, when you run Puppet the first time, HAproxy will be configured to use the certificate from this path. During the second Puppet run, if the path did not change in the Puppet catalog, Puppet won't do anything. Even if the actual file changed, Puppet is not aware of that because Puppet does not manage the actual file, but the parameter in haproxy.cfg. If we want TripleO restarting HAproxy if the certificate changes, we need to patch puppet-tripleo to manage the actual file, with a File resource. Then, if the file change, we'll be able to notify HAproxy Service resource in Puppet and this bug won't occur again. So conclusion: this bug is not a bug but an expected behavior for now. If we want to be able to restart HAproxy everytime certificate changes, that would be an RFE.
Yeah, making this an RFE is totally fair. I mostly wanted to get something open to track this because it's confusing behavior that we should address wherever is appropriate. Your suggestion makes perfect sense to me.