Pipeline rules breaking link to associated stages when renamed

[gimmic]

When changing the rule name in a pipeline rule it is not automatically updated on any stages that rule is associated with, instead the link is 'broken' in the pipeline stage. This does not seem correct when seemingly everywhere else in the graylog infrastructure a renamed object remains linked to any existing configurations.

Expected Behavior

Changing a pipeline rule name should automatically update any linked stages with the new rule.

Current Behavior

Changing a rule name silently breaks the association to existing rules: "Rule [rule name] has been renamed or removed. This rule will be skipped."

Possible Solution

Either provide a warning when saving a rule name on the pipeline rule editor that the rule is currently linked to $Stage.Name or prevent the rule name from being applied if it is currently attached to a stage(similarly to being prevented from removing streams associated with inputs?)

The best solution would be to silently update the existing reference from the old rule name to the new one on the pipeline stage associated with it. The user is already editing the rule associated with that stage and assumes the change will be reflected upstream.

Steps to Reproduce (for bugs)

1. Create a pipeline rule and associate it to a stage
2. Update the pipeline rule code and change the rule name
3. Use the simulator to test your code changes, notice the changes are not reflected
4. Look at the stages in the pipelines and realize there is an error with the updated rule link.

Context

I spent too long troubleshooting why new pipeline extractor rules were not functioning as expected while doing dynamic changes, not noticing that the rule I was editing was not actually associated to the pipeline stage as I expected anymore.

• Graylog Version: 3.0

[kroepke]

While I understand that the behavior is different to many other places, the intention was to have a library of rules which can be shared. That might not be obvious.

Even though it does work as designed its behavior is annoying and can break deployments as you noted, so I'll keep it open for our reference when looking at how to improve the system.

Many thanks for your feedback!

[artiomello]

I'm amazed how this seemingly obvious problem hasn't been fixed for what seems to be 2.5 years and counting.

"...the intention was to have a library of rules which can be shared" - and rules are objects, whatever their content (reusable, shared or otherwise), that should have a unique ID, much like any other entity in Graylog that is referred to by its object ID (completely disregarding the fact that they also have a human readable name, e.g. #13628). And this is the place that it was decided to go with name mapping instead.

This should be fixed, as it indeed breaks the overall logic.

[boosty]

I think adding a warning when renaming a rule (mentioned as one of the possible solutions in the description) could be a good next step.

[artiomello]

I don't see how this fixes anything, but at least it would provide an indication as to why suddenly everything stopped working.

[jrunu]

In the rule editor view pipelines that use this rule are linked. So the association is already there internally. From experience I know that the dance you have to do as of today to rename a function and make sure everything continues to work is a major point of friction in maintenance. (Fixing naming and convention issues is not done, rules existing prior to cleanup efforts are conveniently ignored, etc.)

And while, yes this is a nitpick, the current state of things also means that you will have a gap in processing that is unavoidable.