-
Notifications
You must be signed in to change notification settings - Fork 693
feat: add support for DeleteExporter request handling in broker (#35324) #36516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi @deepthidevaki, I noticed that I had to duplicate some logic between the disableExporter and deleteExporter paths. |
17ecb7e
to
30ee4e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great 🚀 Some smaller suggestions
- ❌ We should also handle concurrent deletion of exporters and transition of ExporterDirection. It looks like the existing code already covers this case. However, to ensure please add a test in ExporterDirectorPartitionTransisitionStepTest for concurrently deleted exporters. You can refer
shouldDisableExporterIfConfigChangedConcurrently
for inspiration. - 🔧 You can simplify most of the the assert statements as I suggested. For future
you can follow this suggestion shared in the slack.you can make use of this plugin, if you are an intellij user.
public ActorFuture<Void> deleteExporter(final String exporterId) { | ||
return callRemoveExporter(exporterId); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can merge this with the disableExporter
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I call inside the deleteExporter -> disableExporter, is that's what you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can just have one public method "removeExporter" in ExporterDirector that is used for disabling and deleting.
...c/test/java/io/camunda/zeebe/broker/system/partitions/PartitionConfigurationManagerTest.java
Show resolved
Hide resolved
...c/test/java/io/camunda/zeebe/broker/system/partitions/PartitionConfigurationManagerTest.java
Outdated
Show resolved
Hide resolved
...c/test/java/io/camunda/zeebe/broker/system/partitions/PartitionConfigurationManagerTest.java
Outdated
Show resolved
Hide resolved
30ee4e6
to
98627d0
Compare
import org.junit.Rule; | ||
import org.junit.Test; | ||
|
||
public class ExporterDeleteTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we have just one method "removeExporter", there is no need for this test because it will be a duplicate of ExporterDisableTest
.
34bf07c
to
c7f51f1
Compare
…nda#35324) - Implemented broker-side request handling for deleteExporter API - Updated PartitionConfigurationManager and ZeebePartition to support exporter deletion closes camunda#35324
update method to deleteOrDisableOrEnableExportersIfConfigChanged in order to handle delete and not just disable or enable. Test updated
c7f51f1
to
01a843c
Compare
context.getExporterDirector().removeExporter(exporter.getId()); | ||
} else if (!currentEnabledExporters.containsKey(exporter)) { | ||
// Exporter present but disabled → disable it | ||
context.getExporterDirector().removeExporter(exporter.getId()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Is this change necessary? The previous code already handles the deleted exporters right?
@giampa91 Would you have time to finish up this PR? If not I'm happy to take over and get it merged. I would like to complete this feature by end of this week because I want to include this feature in the upcoming alpha release scheduled for next week. For the feature, we have to merge this PR and work on the one remaining issue to expose the endpoints. So I would like to merge this by EOD tomorrow at the latest. Please let me know if you have time to answer my question above and make changes if necessary. If not, I will take over and merge your PR with minor changes if necessary. Thanks a lot for your contribution. 🚀 |
@deepthidevaki Sorry for the late! I’m quite busy at the moment and won’t be able to take a look before tomorrow evening at the earliest 😅. From what I can see (please correct me if I’m wrong), the feature is pretty much done and just needs some cleanup. Please feel free to take it over of course I’m happy to contribute 😃! |
@giampa91 Thanks for your reply. Then I will take over this PR and merge it. |
I opened a new PR #36986 with the following changes.
|
## Description When exporter is deleted, it is removed from the runtime state by the ExporterDirector. Concurrent changes during transition are handled by ExporterDirectorTransitionStep already. Since disable and delete behaves similar with in ExporterDirector, the method is renamed to "removeExporter". The original PR for this feature is #36516 by @giampa91 ## Checklist <!--- Please delete options that are not relevant. Boxes should be checked by reviewer. --> - [ ] Enable backports when necessary (fex. [for bug fixes](https://github.com/camunda/camunda/blob/main/CONTRIBUTING.md#backporting-changes) or [for CI changes](https://github.com/camunda/camunda/wiki/CI-&-Automation#when-to-backport-ci-changes)). ## Related issues closes #35324 closes #35323
The changes in this PR are merged via #36986 |
Description
Checklist
Related issues
closes #35324