| Table of Contents |
|---|
| Info |
|---|
Note that in multi-Master Controller environments, the configuration needs only to be updated in the primary Master Controller. The secondary and other Master Controllers will normally receive the configuration by means of synchronisation. |
Importing new files from root
Select root and click the <Import> button
The import window appears showing all new and changed files
After clicking <OK> all files are imported into the database with a temporary version called "uncommited" and synch level 9 which means they will not be synchronised.
All newly imported files are already marked as default during this session with a yellow highlight, but all changes are temporary and only exist in memory during the config manager session until <Save all> button is pressed.
When clicking <Save all> the user can choose to add a comment to the new revision (or not) and when clicking <yes> a new revision is created and all config changes from that session are made final.
For new files this means they will get a new version and synchLevel 11 and they will be officially part of the active config revision.
Import changed files from root
When there already is an active config revision and an import from root is done, the import dialog will show in the first tab all new and changed files
The missing configurations tab will show the files that where present in the current config revision but not in the new import from root. When selecting "Deactivate missing configuration files" those files will be removed from the current active revision
A changed config file will have a new file listed in the table with version "uncommitted" and synch level 9 which means it is temporary, but it is highlighted in yellow to show that it will be part of the active config revision (currently only in memory).
A deactivated config will not have a higlighted version in the table anymore.
Only until clicking <Save all> a new revision is created and all config changes in memory from the session are made final.
All changes made with the <set active>, <set inactive> and <delete> buttons during the session are also kept in memory and only finalized after pressing <Save all>.
When the user tries to close the config manager and there are changes in memory that are not processed by <Save all> the user gets a message and a question whether het is sure he wants to exit.
Single file changes
Besides changing the config revision by import there are also options to activate, deactivate or delete config file versions. These changes will also be kept in memory and only made final after <Save all> is pressed and a new revision is created.
Set active
When an inactive config file version is selected it can be made active by clicking the <Set Active> button
Afterwards, the activated version will be highlighted in yellow to show it belongs to the new config revision the user is working on. The change however will only be made final after <Save all> is clicked and a new revision is created.
Set Inactive
When an active config file version is selected it can be made inactive by clicking the <Set Inactive> button
Afterwards, the deactivated version will not be highlighted in yellow anymore because it will not belong to the new config revision the user is working on. The change however will only be made final after <Save all> is clicked and a new revision is created.
Delete
When an inactive config file version is selected it can be deleted by clicking the <Delete> button
After this the deleted version will not be visible in the table anymore. The change however will only be made final after <Save all> is clicked and a new revision is created.
Deleting older versions needs to be done with care if it will be desired to restore older config revisions later on.
Deleting a sub-directory
When all files within a sub-directory are deleted, then a sub-directory can be deleted too, by either pressing the Delete button or clicking on the Delete context menu option.
Exiting without "Save all"
When the user made config changes and tries to exit Delft-FEWS without having pressed <Save all> a popup will show with a warning.
Restoring old revision
In the Version Management tab a table with all revisions stored in the database is shown.
When selecting one, the list with all changes between the revision from the dropdown list are shown.
When pressing the restore button all config files belonging to that revision will be considered as active in the session. The user has to click "Save all" and create a new revision to make the changes final.
When the user already made config changes without pressing "Save All" and then clicks the restore button a warning will popup because it causes all current changes to be reverted.
When the user tries to restore a revision which contains a file that has been deleted a warning will popup
If the user clicks yes, the deleted file will be removed from the revision. So after "Save All" has been pressed the old revision is restored but the deleted file is removed from it.
Deleting single revisions
The Delete button deletes a selected inactive revision. The Clean up button cleans up all config files which are not referenced by any revision anymore:
Deleting a revision can be useful when there is no more interest in that specific revision, when users will never want to go back to it or check what was / is in there.
It is not possible to delete the active revision.
When older config file(s) or older config file versions are deleted, older revisions that they belonged to will become incomplete, that can also be a reason for deletion.
When a config revision is deleted, only the database record containing the information of the revision which mainly consists of which versions of which config files belonged to that revision, no config files will be deleted and no changes will be made to which config file version will be active.
When older revisions are deleted, some config file versions may not belong to any stored revision anymore.
It can be desirable to remove all these config file versions in one go, for that the Cleanup button has been added.
The cleanup button will first read all revisions and with that information it will check for all existing config file versions whether they are referenced in any of the revisions. If not, they are deleted.
When there are many (large) config revisions the cleanup action can take quite some time without before deleting any config file, just because reading all config revisions can be time consuming.
Even when there are no or hardly any config file versions to delete this can take quite some time.
During the cleanup action the cursor is changed into a waiting icon and for each deleted config file version a message is logged and at the end the total number of deleted config files is logged as well.
Group By
The Group By button will group module config files by their module when selected.
Below it is seen when the button is not activated, it will use the same directory structure as the files are located on disk
When activated the module config files will be grouped by module (like generalAdapterRun, timeseriesImportRun or transformationModule):
Using the ConfigManager for a Master Controller synchronization pool
The ConfigManager will always operate on a single Master Controller database, also in a multi Master Controller environment. When multiple Master Controllers are always kept in synch, in theory it should not matter which Master Controller database the ConfigManager operates on. In practice however, it is best practice to upload new configuration to one and the same Master Controller of the synchronization pool. Most commonly the database where the upload takes place is referred to as the primary Master Controller. Changes uploaded are then automatically shared among the synchronizing Master Controllers that synchronize the uploaded configuration from that central database.
| Info |
|---|
Always upload new configuration to one and the same Master Controller of the synchronization pool. If by mistake the Config Manager was used to upload a single patch.jar to the secondary Master Controller, this can lead to the secondary MC not seeing al the configuration. In such a case it is advised to use the ConfigManager to upload a minor change (e.g. comment) in the primary MC to make all config files visible again to the secondary Master Controller. This will work if only a single patch.jar has been oploaded to the secondary MC and no other config files or actions like "delete inactive config" have been done. |
Using the ConfigManager in a non-standard Master Controller synchronization pool
A non-standard Master Controller synchronisation pool is for instance when there is an external synchronizing Master Controller (for instance in another geography / organization) that is also allowed to synchronize from the primary Master Controller database, but is not synchronizing back. In this case it strongly forbidden to upload configuration in the external Master Controller database. Any subsequent upload into the primary Master Controller could conflict with the externally uploaded configuration.
| Warning |
|---|
Never use the ConfigManager to upload configuration to a non-primary Master Controller that is not allowed to synchronize back to its own synchronization pool. |
If there has been created such a conflict between configurations, it is normally recommended to remove the conflicting configuration from the external Master Controller using the McRecoveryTool. If for some reason, the external Master Controller is for a short period the primary Master Controller, a temporay measure allowing synchronization back to the central system would indeed prevent the configuration conflicts described above.
F12 config zip upload
It is possible to upload a new config revision at once from a zip file, this will skip the import review dialog, clicking the save all and adding a revision comment.
Within the zip a directory called "config" should be present.
It will replace the whole config revision without extra GUI steps in between.
It will check whether the file is a zip and whether it contains at least some System, Root and Region config files.
Should not be used while Configuration Manager is open, this will cause conflicts.