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

Convention for defining system topics #99

Closed
erikvullings opened this issue Jan 8, 2018 · 3 comments
Closed

Convention for defining system topics #99

erikvullings opened this issue Jan 8, 2018 · 3 comments

Comments

@erikvullings
Copy link

I would like to show our AVRO-based configuration topic under System topics in the UI. Initially, I thought it would be sufficient to name my topic _configuration (like _schemas), but unfortunately, this did not work. To make matters even worse, by preceding my topic with an underscore, the AVRO _configuration-key, and _configuration-value schemas were ignored, and my topic was displayed as binary. I will log this as a separate issue.

When browsing through the source code, however, I noticed that you treat certain topics as system topics if they start with a certain string prefix such as connect-status. And indeed, by renaming my topic to connect-status-configuration, it became a system topic and AVRO deserializing worked again.

So my question is, is it possible to add an option to treat certain topics as system topics, e.g. by prefixing it with an underscore, or 'system-topic'? Or could you include an underscore in your topics.config.js (I can create a pull request for that, if you like...).

@Antwnis
Copy link
Contributor

Antwnis commented Jan 9, 2018

You can control system topics via a variable at line

https://github.com/Landoop/kafka-topics-ui/blob/master/src/topics.config.js#L11

So you can pull the latest code, add your topic-name in that list of system/topic/names
and build the project. Whatever is there in CONTROL_TOPICS we do a if (topicName.startsWith(_))

It's easy to tweak a bit the code - and rebuild

@erikvullings
Copy link
Author

Yeah, sure, but that also means that every time you add a new feature, I would have to merge the source code again. Wouldn't it be better if you define an environment variable for it?

@stheppi
Copy link

stheppi commented Jan 10, 2018

@erikvullings fancy doing a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants