Configurer specification - partial configurations and merging (R8+)

[bjhargrave]

Original bug ID: BZ#224
From: Elias N Vasylenko <elias@vasylenko.uk>
Reported version: R6

[bjhargrave]

Comment author: Elias N Vasylenko <elias@vasylenko.uk>

As discussed previously here https://mail.osgi.org/pipermail/osgi-dev/2017-November/006598.html I propose support for some way to provide partial configurations for a PID and have the configurer merge them as appropriate.

Peter Kriens has shown that at least some users want this and that it's feasible to provide.

I think this is best served by allowing a configuration to mark itself as an override. If the configurer then chooses it as the highest ranked configuration, it knows that it is incomplete and must be merged with the configuration of the next highest ranking.

This achieves two important properties:

• An incomplete configuration is never deployed without an existing complete configuration to be overridden.

• Control of how a configuration is merged is given to the entry with the highest ranking.

Take the following configurations as an example:

[Bundle A]
{
"my.pid": {
":configurator:ranking": "0",
"key_one": "configured_value",
"key_two": "configured_value",
"key_three": "configured_value"
}
}

[Bundle B]
{
"my.pid": {
":configurator:ranking": "1",
"key_three": "overriding_value",
":configurator:merge-strategy": "override" // just a suggestion for illustration
}
}

Here bundle B's configuration can't be deployed by itself, but with the presense of bundle A as well the configurer would infer the following resulting configuration:

[effective]
{
"my.pid": {
"key_one": "configured_value",
"key_two": "configured_value",
"key_three": "overriding_value"
}
}

I think this approach is powerful enough to justify the extra implementation complexity and does not add much burden to the mental model for users. It would probably require a version bump for ":configurator:version".

[bjhargrave]

Comment author: Elias N Vasylenko <elias@vasylenko.uk>

One consideration I forgot to mention is that this this would interact with the overwrite policy in a tricky way. Different keys in the effective configuration may have been merged in from configurations which used different policies.

Building on the example above:

• Let's say bundle A has specified "force" policy on its configuration and bundle B has "default".

• At runtime another bundle then provides a manual configuration for "my.pid" through the configuration admin.

• Bundle A and B are then redeployed, what happens now?

I think the natural behaviour is to keep the manual configuration for "key_three" but revert "key_one" and "key_two" to the values given by bundle A.

It could be nice to be able to have different policies apply to different properties ... but as a general mechanism for allowing that this is pretty clunky since it can't be done in a single configuration.