f32a31d585
Existing rsync stop/start handlers were relying on the pattern parameter to the Ansible service module which relies on the results of ps to determine if the service is running. This is unnecessary because the rsync service script is well-behaved and responds appropriately to start stop and restart commands. Removal of the pattern param ensures that the response from the service command is used instead. Root cause of the bug is that when Keystone was changed to share fernet secrets via rsync over ssh tunnel, an rsync process was introduced in AIOs, Swift stand-alones, and other deployment configurations that contain Keystone containers on the storage hosts. The resulting rsync processes within Keystone containers pollute the results of ps commands on the host, fooling Ansible into thinking that an rsync service is running on the standard port when it is not. Secondly, the handler responsible for stopping rsync was not causing the notice for "Ensure rsync service running" to trigger cleanly in my testing, so the tasks were changed to trigger both notices in an ordered list. Change-Id: I5ed47f7c1974d6b22eeb2ff5816ee6fa30ee9309 Closes-Bug: 1481121 |
||
|---|---|---|
| .. | ||
| main.yml | ||
| swift_install.yml | ||
| swift_post_install.yml | ||
| swift_pre_install.yml | ||
| swift_proxy_hosts.yml | ||
| swift_service_setup.yml | ||
| swift_storage_hosts_account.yml | ||
| swift_storage_hosts_container.yml | ||
| swift_storage_hosts_object.yml | ||
| swift_storage_hosts_setup.yml | ||
| swift_storage_hosts.yml | ||
| swift_upstart_common_init.yml | ||