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
595c007ac2