You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: