Adapt routing key template to Sepia about eiffel-remrem-semantics HOT 10 OPEN

Had some internal discussions regarding the new routing key template. For this enhancement, there need to be discussions held at higher level. Based on those discussions, I will add the update.

And the maximum limit for RabbitMQ routing key is 255 characters. We should also consider this.

from eiffel-remrem-semantics.

For a better understanding of this issue I strongly recommend this recording from the last Eiffel Summit, about the new routing key schema: https://www.youtube.com/watch?v=dz5rm13Gw-Y

from eiffel-remrem-semantics.

During a discussion, we concluded that it would be good to have the routing scheme as a configuration. The default routing key schema should reflect the current Sepia description but then make it possible for the user to deploy an instance of REMReM with a legacy routing key schema.

from eiffel-remrem-semantics.

Had a internal discussion with team and decided to start implementation to the new Routingkey adaption.
Our proposal on the property name of legacy routing key schema to maintain backward compatibility is "EnableLegacyRoutingKeyFormat".
Please let us know if you have any other suggested name for this new configuration.

from eiffel-remrem-semantics.

I would prefer that we don't include something called "Legacy" in the REMReM code or config params. I would instead propose that the routing key format could be overridden by a user provided config file, that would provide the mapping from the new proposed routing key format to any custom format. When deploying REMReM in for example Ericsson you could then internally provide such a config file for the "legacy" names and apply it to the service internally.

from eiffel-remrem-semantics.

Agree with @e-backmark-ericsson

from eiffel-remrem-semantics.

Yes we will provide the property in the configuration file But we haven't decided on the configured property name and would like to take your suggestion on the name.
We also have one more query regarding the publish-cli. As cli do not have the configuration file, do we need to introduce new cli option for the same.

from eiffel-remrem-semantics.

I believe the configuration file property names should be inline with the Sepia naming conventions, and its values could then be whatever each organization wants to set. I'm not sure what config file format you will use, but if it would be a simple key-value cfg file it could be called "routing-key-overrides.cfg" and the contents, when deployed in Ericsson, could be something like this:

...
EiffelArtifactCreatedEvent.family = artifact
EiffelArtifactCreatedEvent.type = created
...
EiffelEnvironmentDefinedEvent.family = cm
EiffelEnvironmentDefinedEvent.type = environment
...
EiffelTestCaseTriggered.family = test
EiffelTestCaseTriggered.family = triggered
...

This file is optional, and it should not be part of the repository, but instead stored somewhere in Ericsson together with other Ericsson specific Eiffel code. For documentation purposes you could of course provide an example config file within the repo, but it should not be considered the production file for Ericsson as its content could be different from what Ericsson would need.

Regarding the publish-cli, yes it would probably be good to add a cli option for providing this optional config file.

from eiffel-remrem-semantics.

We are configuring the optional property "semanticsRoutingkeyTypeOverrideFilepath" in publish-service properties file. When we specify the property, the service read the contents present in the file and prepares the routing key with the specified type. The file format will be as below
...
EiffelActivityCanceledEvent.type=canceled
EiffelActivityFinishedEvent.type=finished
EiffelActivityStartedEvent.type=started
...

we will also add the new cli option to read the routing key property file in publish-cli.
Note: The default routing key format will be the newly adapted routing key template to Sepia.

from eiffel-remrem-semantics.

Just adding a comment, for reference: Interesting input to this topic was discussed in the Eiffel Summit 2021, under the heading Event Type Categorization. Providing the possibility to configure the families when deploying REMReM makes it possible to have context/user specific event type categorization.

from eiffel-remrem-semantics.