Looking for some resolution on the "No Topics" change. I am thinking that using null in the protocol isn't that complex, and it avoids various edge cases with having multiple fields. That leaves us with 2 options:
- A: null = no topics, empty = all topics - B: null = all topics, empty = no topics A is nice because it just adds new functionality, existing logic doesn't change B is nice because its more "intuitive", but has the drawback of changing what empty means from request v0 I do not have a strong opinion on the approach taken, which makes me lean towards option A. Keep in mind at the user level, the apis in the various clients can map this however they like. Does anyone feel strongly about the choice? On Thu, Mar 31, 2016 at 9:21 AM, Grant Henke <ghe...@cloudera.com> wrote: > 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 > -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
