Alert handing changes:

[wagmarcel]

* Alerts are ignored if the related rule is not active
* Alerts of resetType "Manual" trigger only actions if there is no existing unsuppressed alert with state "New"
* If Alerts are not triggering but valid, they are stored in DB as suppressed events
* GUI is only showing active, i.e. non-suppressed event
* URI parameter "active=true" can be used to get only non-suppressed event. Default behavior is to provide all events.

Signed-off-by: Marcel Wagner wagmarcel@web.de

[wagmarcel]

@oguzcankirmemis I streamlined the createDB script to make it succeding (I need it for the Helm Hook PR in Platformlauncher). But I think there is some rework needed, especially on the testdb usage and creation.

[wagmarcel]

@oguzcankirmemis dont merge it -- I found an issue with it.

[oguzcankirmemis]

@wagmarcel there is a small thing I noticed in the createDB script: If I am not mistaken, with superuser account the initial database is created and then the superuser that is already there is created again. Is this intended?

Here is the line where it is happening.

I could also see that the script trying to grant permission to normal user before it is ever created. Normally what should happen is:

• Superuser connects to postgres
• Creates the main and the test databases
• Creates the normal user
• Grants permissions to user for the created databases

[oguzcankirmemis]

@wagmarcel Sequelize cannot take model definitions from postgres or migration files and migration files can't take vice versa (here is the issue). The best solution that comes to my mind:

• Copy the current model definitions as an initial migration file
• Create the migration file for alerts
• Update the model definition for alerts
• Remove createDatabase and initSchema functions entirely, frontend should never attempt to create or update the database itself
• Rewrite admin/createDB script to use sequelize migratons (and update/remove other admin/*.js scripts if necessary)
• For future changes, create a new migration file, also update the model to be up to date.

If frontend version is newer or older than migration, then it should fail and crash. So we only have to make sure that each frontend version is consistent in terms of its model definitions and migration files.

[oguzcankirmemis]

We should actually also remove admin/createDB entirely, and use updateDB for database creation and updates, because it does not make any sense if we have the initial migration file. The resetDB should delete the whole database and use updateDB afterwards to create and bring the database up to date.

[wagmarcel]

@oguzcankirmemis: not sure about skipping createDB. Then we need to differentiate whether updateDB is creating from scratch or only apply migration scripts. The way it is done in this PR (actually with the related PR in platform-launcher) is that helm install is applying createDB and updateDB and help upgrade is only applying the migration scripts.

[oguzcankirmemis]

@wagmarcel Seems reasonable, but then createDB still should not depend on models and only apply the initial migration. Otherwise we would have problems.

[wagmarcel]

@oguzcankirmemis: The PR is now ready for review. Besides the Alert changes, the db migrations works now as follows: createDB is using the "base" Alerts model (migrations/models). The updates are in migrations/migrations. With that, the install can be done by using createDB && updateDB. The upgrade can be done by only using updateDB.