frmscoe / General-Issues

This repo exists to track current work and any issues within the FRMS CoE
2 stars 0 forks source link

Explicitly reference the typology processor in the network map and typology configuration #296

Closed Justus-at-Tazama closed 3 months ago

Justus-at-Tazama commented 9 months ago

Story statement

As an EKUTA platform operator, I want to be able to deploy different typology processors in my evaluation flow, So that I can perform typology aggregation in different ways for different types of typologies.

Acceptance criteria

  1. Create a separate processor identifier from the (current) typology identifier: a. The current id attribute in a typologies element (and in fact in every processor in the network map) is supposed to identify the specific typology processor and version that will be used to evaluate a typology, but in our current implementation, the key-value pair: "id": "001@1.0.0" actually identifies the typology (and as a result the version text following the @ is redundant and assumed to always refer to the version of the only typology processor in the platform). It should be possible to operate multiple parallel typology processors in the platform, and also multiple versions of the same typology processor, coordinated through the network map. To fulfil this requirement, the id attribute should refer to the specific typology processor and version, while the cfg attribute should refer to the typology and configuration version. In other words:
"typologies": [
  {
    "id": "typology-processor@1.0.0",
    "host": "NATS Server",
    "cfg": "001@1.0.0",
    "rules": [
    --
    ]
  }
]

b. The typology processor "name" is somewhat arbitrary, but it would make sense to name the typology processor in the configuration after the repository where the typology processor code comes from, i.e. "typology-processor". c. The change to the typology identifier should follow through to the typology configuration as well.

{
  "id": "typology-processor@1.0.0",
  "cfg": "001@1.0.0",
  "workflow": {
    "alertThreshold": 2200,
    "interdictionThreshold": 2600
  },
  "rules": [
    --
  ]
}
  1. Update the Sybrin configuration manager to absorb the change to the typology configuration implementation.