kfaraz commented on issue #18008: URL: https://github.com/apache/druid/issues/18008#issuecomment-2940942104
> I'm slightly against supervisor UUIDs since that might make things less readable on the console (users would have to look at the spec to get an idea of what topic, etc. it's pulling from). @jtuglu-netflix , that is easily remedied since the web-console is powered by the `sys.supervisors` table which itself reads from an Overlord API. So, it would be fairly straightforward to add a datasource column to web-console. We would need to add this column anyway regardless of the approach we take since supervisor IDs can now deviate from the datasource name. > My thought is we keep the same supervisor ID scheme and just validate as we normally do via the id uniqueness constraint in druid_supervisors table. Do you mean something like supervisor 1 with `id = user-given-id-1` and supervisor 2 with `id = user-given-id-2`, both can write to the same datasource? That would work too. In fact, that is what I had in mind when I mentioned removing the 1:1 relationship between datasource and supervisor in [this older comment](https://github.com/apache/druid/issues/18008#issuecomment-2915281098). Optional: We might also want to consider adding some more validations in the same vein as #17955 so that users don't accidentally update a supervisor when they actually intended to create a new supervisor to write to the same datasource but read from a different topic/cluster. > I agree that druid_dataSource would need a supervisor_id column. As for APIs, I feel like keeping them the same for now is fine. The only new addition might be getting the full list of supervisors for a given datasource, which can be done by pulling the list of supervisors from druid_supervisors and filtering on datasource outside the query. Sounds good. This new API need not read from metadata store though, the `SupervisorManager` should already have all the necessary info cached in memory. Also, if we do the modifications with the `sys.supervisors` table suggested above, we probably wouldn't need this API. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
