Looking at this a bit more, there is a lot going on here and it is intrinsically tied to the blueprint plugin re. the actual configuration:

• we rely on blueprint to populate the configuration, but then

• examine it and potentially generate password details, except

• all of that is not used, as we hard-code stuff at compile-time

Let's split the effort up. As a first step, we will separate out configuration update concerns into a separate class wired through Blueprint (for now) and let AAAEncryptionServiceImpl pick up its configuration from OSGi SR and instantiate with OSGi DS. This will lead to an OSGi DS component being dependent on Blueprint, which is kind of okay and unblocks upstreams.

The second part is to re-wire the configuration template/update wiring to work without blueprint and without initial config file.

So I think this is problematic, because AAAEncryptionService is used by NETCONF to encrypt things in the datastore. Most notably we need a way to decrypt things as well.

That means the configuration is coupled with datastore content, which unfortunately, is a very loose coupling.

I think we need to retain the config datastore integration and do the heavy lifting through org.osgi.service.component.ComponentFactory, meaning register a ClusteredDataTreeChangeListener on component startup and activate a service configuration. We already do this (without datastore, but reacting to OSGi SR) in mdsal-binding-runtime-osgi).