Design and Implement Configuration Migration

[jpdillingham]

Presently the ConfigurationManager stores strongly typed configuration models in the configuration file. Should a downstream asset update its model, the ConfigurationManager needs a way to migrate the previous configuration to the new model.

Initial thoughts are to implement a ConfigurationMigration/IConfigurationMigration to be used with the Discoverer. Implementations could have [ToVersion] and [FromVersion] attributes, allowing the ConfigurationManager to determine which migration to apply.

Migrations should be additive in that an upgrade from 1.0 to 3.0 should apply migrations for 1.0 -> 2.0, then from 2.0 -> 3.0. A migration setup for this scenario might look like the following:

[FromVersion(1.0.0.0)]
[ToVersion(2.0.0.0)]
public Migration1to2 : IConfigurationMigration { }

[FromVersion(2.0.0.0)]
[ToVersion(3.0.0.0)]
public Migration2to3 : IConfigurationMigration { }

The ConfigurationManager would need to collect all migrations and examine the versioning attributes to ensure an upgrade path is available. After migration is complete the deprecated configuration would be removed from the config (and probably backed up somewhere).

[jpdillingham]

@adamopan thoughts?

[jpdillingham]

Here's a present configuration section for the WebApiService Type:

  "OpenIIoT.Core.Service.WebApi.WebApiService": {
    "": {
      "Port": 80,
      "Root": "openiiot"
    }
  }

At one point the full Type name was used as the key; in this scenario that would need to return or a composite key for the dictionary would be needed (or maybe just tack the version on to the name and use a string).

Additionally versioned configuration models will need to be retained from version to version for this to work. Perhaps the configuration dictionary should be keyed on the configuration model type, not the asset it belongs to.

[jpdillingham]

I'm also beginning to doubt the need for named instances of the same configuration. I'll create a separate issue for that.