Sources are right now hard-linked with every object and rule. It gets more and more clear to me that this linkage isn't suitable anymore and must be softened.
Do not incorporate source id into how object ids are generated
From the perspective of a source, the object_tags are the sole information to identify an object and differentiate it from others. Right now, the source id, an autoincrement integer, is being taken into account plus said object tags, in case Icinga Notifications constructs an object's id. This is wrong and prone to accidental object duplication, very similar to what happens in case Icinga DB accidentally gets a different environment id with the otherwise same configuration. If object tags are not enough to prevent duplicates across a source, a source has to provide more unique object tags.
If objects of different sources conflict, because they happen to use the same tags, that's fine. Separate rules, as filters depend on the source, are to be expected as well. But it's already expected that different rules apply to the same incident anyway.
The object table therefore doesn't need to have a source_id foreign key anymore, but for the visual experience in Icinga Notifications Web I still like to see a link between sources and objects, but in a nm relation.
Allow more than one source be a provider for a particular escalation rule
This changes the 1n relation of source <- rule to a nm relation source <-> rule instead. Icinga Notifications Web already does not require a particular source for an escalation rule, it only needs a type identifier. The same must therefore be the case for Icinga Notifications as it must then be able to identify rules the same way.
This opens up the possibility of a contradiction as it must be invalid for differently typed sources being linked with the same escalation rule. Icinga Notifications Web is responsible to ensure this but the database should also forbid this by using appropriate constraints.
Sources are right now hard-linked with every
objectandrule. It gets more and more clear to me that this linkage isn't suitable anymore and must be softened.Do not incorporate source id into how object ids are generated
From the perspective of a source, the
object_tagsare the sole information to identify an object and differentiate it from others. Right now, the source id, an autoincrement integer, is being taken into account plus said object tags, in case Icinga Notifications constructs an object's id. This is wrong and prone to accidental object duplication, very similar to what happens in case Icinga DB accidentally gets a different environment id with the otherwise same configuration. If object tags are not enough to prevent duplicates across a source, a source has to provide more unique object tags.If objects of different sources conflict, because they happen to use the same tags, that's fine. Separate rules, as filters depend on the source, are to be expected as well. But it's already expected that different rules apply to the same incident anyway.
The
objecttable therefore doesn't need to have asource_idforeign key anymore, but for the visual experience in Icinga Notifications Web I still like to see a link between sources and objects, but in anmrelation.Allow more than one source be a provider for a particular escalation rule
This changes the
1nrelation ofsource <- ruleto anmrelationsource <-> ruleinstead. Icinga Notifications Web already does not require a particular source for an escalation rule, it only needs a type identifier. The same must therefore be the case for Icinga Notifications as it must then be able to identify rules the same way.This opens up the possibility of a contradiction as it must be invalid for differently typed sources being linked with the same escalation rule. Icinga Notifications Web is responsible to ensure this but the database should also forbid this by using appropriate constraints.