595c007ac2
The patch services(sw-patch-agent and sw-patch-controller-daemon if the node is a controller) are expected to reload if the patching config changes. However, the subscription on File[$::patching::params::patching_conf] starts after the configuration of keystone_authtoken, which results the services still using the old configure. This commit applies the sw-patch-agent.service and sw-patch-controller-daemon.service to the Patching_config collector, so the services will be reloaded after any value in patching_config changes. Tests: 1 Installed and bootstrapped an AIO standalone system and a standard duplex subcloud. 2 Manually modify the keystone password configuration, lock/unlock the nodes, the start time of sw-patch-agent and sw-patch-controller-daemon are later than the timestamp of the configuration file. 3 Issue a "dcmanager subcloud add --migrate" command to migrate the subcloud to another central cloud, during the migration, the hieradata is aligned with the new central cloud, but the configuration on controller-1 remains. After lock/unlock the controller-1 in the subcloud, the subcloud can get managed and the patching_sync_status and load_sync_status can get in-sync Closes-Bug: 1929595 Signed-off-by: Yuxing Jiang <yuxing.jiang@windriver.com> Change-Id: I923c9e88c9b53d2ba4bf8fb43aa9dabf1bbb728e