Is your feature request related to a problem? Please describe.
Currently, when JulieOps deserializes a topology, it requires Streams users to have a topics.read block with at least one topic, throwing an IOException if this is not the case. While this makes sense in isolation, our organization prefers granularly configuring read/write access in the main topics block.
This check does not exist for other user types, such as KSQL or Connect.
Currently, the deserialization requirement forces us to specify read/write access differently for Streams users. We would like to have a consistent method of specifying read/write access
Describe the solution you'd like
Remove the check in TopologyCustomDeserializer that throws an IOException if there are no "Read Topics"
Describe alternatives you've considered
The status quo is workable, but a consistent process is preferred
Additional context
N/A
Is your feature request related to a problem? Please describe.
Currently, when JulieOps deserializes a topology, it requires Streams users to have a topics.read block with at least one topic, throwing an IOException if this is not the case. While this makes sense in isolation, our organization prefers granularly configuring read/write access in the main topics block.
This check does not exist for other user types, such as KSQL or Connect.
Currently, the deserialization requirement forces us to specify read/write access differently for Streams users. We would like to have a consistent method of specifying read/write access
Describe the solution you'd like
Remove the check in TopologyCustomDeserializer that throws an IOException if there are no "Read Topics"
Describe alternatives you've considered
The status quo is workable, but a consistent process is preferred
Additional context
N/A