With the introduction to text-based configuration files, what is the role of the tables within the db/config.idb database that seem to have been migrated to configuration files?
Post migration, it seems like the majority of the gateway configuration that now has a config.json still exist as a table within the config.idb database.
I've landed on a couple rationalizations, either may be true or false, but some clarification may help:
- The existing "migrated" tables in
config.idb, post-migration, are still relevant and are being used, but the configuration files takes precedence after a configuration scan / startup. - Only some "migrated" tables in
config.idbare still relevant post-migration, and some tables are ignored entirely but have not been dropped for durability/reliability of the migration process.
Of course, meddling with config.idb is not something for the faint of heart, but the intention here is to better understand the migration process and how to minimize the time it takes to bring a production 8.3 gateway online from an 8.1 backup.
My end goal here is to have a known configuration which can be committed to source control that is defined in terms of the config directory, ignition.conf, logback.xml,gateway.xml, ... et cetera.
Whether or not it is possible to run a targeted migration on an 8.1 gateway backup that would only bring over what is not contained within these plaintext configuration files (e.g. tag configurations, internal user sources, ???) is one question I am entertaining, that perhaps the wider Ignition community has answers to.
The most well-documented approach in my experience seems to be running a migration on an 8.1 .gwbk file and overlaying the desired configuration files on the migrated data/ folder. One issue on this, is that it may take some amount of time to run this "offline" migration, and I would like to try to optimize this migration process to minimize the amount of time the 8.1 gateway would be running while I have a captured .gwbk that is being migrated to be used in the 8.3 gateway. For instance, if most of my configuration is already determined by the well-known configuration in a textual config directory, I would like to only migrate what is not represented there.
It seems to me that the migration seems to leave behind some crumbs in this config.idb file, which I would ideally like to avoid if possible to have a clean state, where the 8.3 migration machinery believes that this gateway was running 8.3 from the very beginning of time.
Does anyone have any wisdom to share in this domain? I feel like I am on the right track, but if anyone has any recommendations or resources I had missed while researching (even the obvious ones!) I would greatly appreciate it.