Skip to content
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

Loosen Streams Deserialization Requirements Around Read Topics #539

Open
eazamaAU opened this issue Sep 9, 2022 · 0 comments · May be fixed by #540
Open

Loosen Streams Deserialization Requirements Around Read Topics #539

eazamaAU opened this issue Sep 9, 2022 · 0 comments · May be fixed by #540
Labels
enhancement New feature or request

Comments

@eazamaAU
Copy link

eazamaAU commented Sep 9, 2022

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

@eazamaAU eazamaAU added the enhancement New feature or request label Sep 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant