In order to be instantiated the service relays on dataBroker event providing current configuration to use. If no event occurs (properly delivered) then password hash service wont be activated. While the root cause of notification event absence could be related to DataBroker implementation, the event absence should not be a reason why password service is not activated.
Suggested the service update
Current implementation uses a configuration factory to instantiate a configuration component which then used as a reference to activate the password service intance. It seems reasonable to make a direct service factory instead. It's extra to make a configuration to be an OSGi component.
Also default configuration require to be persisted if datastore contains no configuration. See encryption service implementation as example
Okay, so after adding a few strategic debugs, the problem is in OSGiPasswordServiceConfigBootstrap, as evidenced by this:
Essentially what happens is that as part of registerDataListener(), the calling thread gets suspended (opendaylight-cluster-data-akka.actor.default-dispatcher-16) and a bunch of other threads get to run, delivering the change notification on a completely different thread (opendaylight-cluster-data-notification-dispatcher-35), which sees 'registration' as null, as dispatcher-16 is suspended before it stores 'registration' – thus the thread does nothing.
The issue appears on NETCONF build while executing SFT on features where password service is involved.
Periodiacally OSGiPasswordHashService is not initialized properly, resulting dependent services remain in Waiting state leading to SFT failure.
Diagnostics message in logs is like below
see https://jenkins.opendaylight.org/releng/job/netconf-maven-verify-master-mvn39-openjdk21/413/
build and SFT logs are attached
In order to be instantiated the service relays on dataBroker event providing current configuration to use. If no event occurs (properly delivered) then password hash service wont be activated. While the root cause of notification event absence could be related to DataBroker implementation, the event absence should not be a reason why password service is not activated.
Suggested the service update
Current implementation uses a configuration factory to instantiate a configuration component which then used as a reference to
activate the password service intance. It seems reasonable to make a direct service factory instead. It's extra to make
a configuration to be an OSGi component.
Also default configuration require to be persisted if datastore contains no configuration. See encryption service implementation as example