Adapt routing key template to Sepia

[e-backmark-ericsson]

Description

Recently a routing key template was added to Eiffel Sepia, through PR https://github.com/eiffel-community/eiffel-sepia/pull/9. REMReM should adapt to that recommendation. It is almost compatible with the current implementation in REMReM, apart from the event type field, which should contain the complete event type name and not just an abbreviated version of it. Suggestion is to provide a configuration option to REMReM to keep the "legacy" (current) strings in the event type field to be compatible with any current REMReM deployments, but with the intention to be phased out in due time. It's recommended to provide this "legacy" option as a deprecated option to highlight that this option might disappear in the future.

Documentation to update

• https://github.com/eiffel-community/eiffel-remrem-semantics/blob/gh-pages/routingAndBindingKeyConcepts.html
• https://github.com/eiffel-community/eiffel-remrem-semantics/blob/master/wiki/templates.md

Motivation

To be aligned between all Eiffel eco system tools that should share the same routing key template. Eiffel Sepia should be seen as the blueprint for interoperability between tools in the Eiffel eco system.

Exemplification

E.g. a Jenkins event consumer can more easily be configured to listen to the wanted events.

Benefits

Increased interoperability between all Eiffel event producers and consumers, as they share the same routing key template.

Possible Drawbacks

Existing Eiffel message consumers & producers using another routing key scheme needs to adapt to the new routing key scheme. The proposed "legacy" option is added to this suggestion to deal with that.

[zburswa]

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.

[e-backmark-ericsson]

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

[m-linner-ericsson]

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.

[Umadevi-Kapu]

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.

[e-backmark-ericsson]

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.

[m-linner-ericsson]

Agree with @e-backmark-ericsson

[Umadevi-Kapu]

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.

[e-backmark-ericsson]

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.

[Umadevi-Kapu]

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.

[e-backmark-ericsson]

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.