Improved detection error with Stream ACLS generation when using custom project and topic formats

Describe the bug The first time I run a topology with ACLs for streams without ´applicationId´ tag it works fine and applies ACLs correctly, but if I try to apply it again we receive an error.

If we delete the .cluster-state file, after the first run, it works file.

I suspect it has something to do with the properties we have defined:

topology.project.prefix.format= topology.topic.prefix.format={{topic}} topology.state.cluster.enabled=true

It looks like some PREFIXED ACLs are being stored in the local .cluster-file. Maybe because of the way these ACLs naming is being processed. And when we run the same topology several times it finds some inquerences that prevent the tool to run successfully.

To Reproduce Steps to reproduce the behavior: Relevant properties:

    topology.project.prefix.format=
    topology.topic.prefix.format={{topic}}
    kafka.internal.topic.prefixes.0=_
    allow.delete.bindings=true
    topology.state.cluster.enabled=true

Topology descriptor: streams:

      - principal: "User:streamsapp"
        applicationId: "streams-appid"
        topics:
          read:
            - topic-A
          write:
            - topic-B

The content of this file after the first run is :

acls ‘GROUP’, ‘’, ‘’, ‘READ’, ‘User:streamsapp’, ‘PREFIXED’ ‘TOPIC’, ‘’, '', ‘ALL’, ‘User:streamsapp’, ‘PREFIXED’ ServiceAccounts Topics

The error we get is:

Exception in thread “main” java.io.IOException: line (‘GROUP’, ‘’, ‘*’, ‘READ’, ‘User:streamsapp’, ‘PREFIXED’) does not match at com.purbon.kafka.topology.backend.AbstractBackend.buildAclBinding(AbstractBackend.java:23) at com.purbon.kafka.topology.backend.FileBackend.load(FileBackend.java:76) at com.purbon.kafka.topology.backend.FileBackend.loadBindings(FileBackend.java:60) at com.purbon.kafka.topology.BackendController.load(BackendController.java:83) at com.purbon.kafka.topology.ExecutionPlan.init(ExecutionPlan.java:57) at com.purbon.kafka.topology.JulieOps.run(JulieOps.java:200) at com.purbon.kafka.topology.CommandLineInterface.processTopology(CommandLineInterface.java:196) at com.purbon.kafka.topology.CommandLineInterface.run(CommandLineInterface.java:144) at com.purbon.kafka.topology.CommandLineInterface.main(CommandLineInterface.java:134)

Expected behaviour As a Julie tool user, I expect it to be idempotent.

Runtime (please complete the following information):

• OS: Mac
• Version 2.0.0

Additional context Having Kubernetes running on Mac. Julie is running on a pod. If there is more information needed or clarified feel free to request it. Thank you for your help.

[purbon]

@Xtema and @akselh #245 should detect and log extensible the problem detected here. I hope it helps.

[purbon]

The problem surfaces in the second run because JulieOps is able to write the invalid ACLs, but not to read them (later) because an empty string for the group is not expected.

Hi @akselh and @Xtema, sorry for taking some time here, but current work load has not allowed me to work lately on the project.

I have been taking a deeper look at the problem.

Is it interesting what you mention, this is what I noticed.

• In the current code version (master), the group name is taken out of _ this.prefix = app.getApplicationId().orElse(topicPrefix);_ what means if applicationId is not set, the topic prefix will be used.
• In your config you use topology.topic.prefix.format={{topic}} and _ topology.project.prefix.format=_ i wonder, if this is what is causing this prefix to be empty.

I will try to prove this hypothesis and propose a fix.

Sorry again for the trouble here, and thanks a lot both for your help testing and contributing!! is very much appreciate it.