> > I had a second look at the proposed changes to Metadata Request and > Response and it seems to me that having a `controller_id` field would be > more efficient for non-trivial cases than having a `is_controller` field > for each broker (which would be false for all but 1 case).
I agree this is better. I will update it. Similar, but less clear is the best way to encode `marked_for_deletion` and > `is_internal`. These will also be false for most topics (there is only one > internal topic at the moment, for example), so it may make sense to have a > topics_marked_for_deletion and internal_topics in the response. Because > topics are identified by strings, it is not as clear-cut as the > controller_id case, but it still seems like it would be a win for when it > matters most (when the number of topics is large). > Thats an interesting idea. I can try making this change to see what it would look like. Thanks, Grant On Thu, Mar 31, 2016 at 8:59 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Grant, > > I had a second look at the proposed changes to Metadata Request and > Response and it seems to me that having a `controller_id` field would be > more efficient for non-trivial cases than having a `is_controller` field > for each broker (which would be false for all but 1 case). > > Similar, but less clear is the best way to encode `marked_for_deletion` and > `is_internal`. These will also be false for most topics (there is only one > internal topic at the moment, for example), so it may make sense to have a > topics_marked_for_deletion and internal_topics in the response. Because > topics are identified by strings, it is not as clear-cut as the > controller_id case, but it still seems like it would be a win for when it > matters most (when the number of topics is large). > Ismael > > On Mon, Mar 14, 2016 at 10:07 PM, Grant Henke <ghe...@cloudera.com> wrote: > > > I have been updating the KIP-4 wiki page based on the last KIP call and > > wanted to get some review and discussion around the server side > > implementation for admin requests. Both the "ideal" functionality and the > > "intermediated" functionality. The updates are still in progress, but > this > > section is the most critical and will likely have the most discussion. > This > > topic has had a few shifts in perspective and various discussions on > > synchronous vs asynchronous server support. The wiki contains my current > > perspective on the challenges and approach. > > > > If you have any thoughts or feedback on the "Server-side Admin Request > > handlers" section here > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-2.Server-sideAdminRequesthandlers > > >. > > Lets discuss them in this thread. > > > > For reference the last KIP discussion can be viewed here: > > https://youtu.be/rFW0-zJqg5I?t=12m30s > > > > Thank you, > > Grant > > -- > > Grant Henke > > Software Engineer | Cloudera > > gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke > > > -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
