For ListTopics, we decided not to add a ListTopics request for now and just rely on passing in an empty list to TMR. We can revisit this in the future if it becomes an issue.
Thanks, Jun On Wed, May 13, 2015 at 3:31 PM, Joel Koshy <jjkosh...@gmail.com> wrote: > Just had a few minor questions before I join the vote thread. > Apologies if these have been discussed: > > - Do we need DecreasePartitionsNotAllowed? i.e., can we just return > InvalidPartitions instead? > - AdminClient.listTopics: should we allow listing all partitions? Or > do you intend for the client to issue listTopics followed by > describeTopics? > - On returning future<void> for partition reassignments: do we need to > return any future especially since you have the > verifyReassignPartitions method? For e.g., what happens if the > controller moves? The get should fail right? The client will then > need to connect to the new controller and reissue the request but > will then get ReassignPartitionsInProgress. So in that case the > client any way needs to rely in verifyReassignPartitions. > - In past hangouts I think either you/Joe were mentioning the need to > locate the controller (and possibly other cluster metadata). It > appears we decided to defer this for a future KIP. Correct? > > Thanks, > > Joel > > On Tue, May 05, 2015 at 04:49:27PM +0300, Andrii Biletskyi wrote: > > Guys, > > > > I've updated the wiki to reflect all previously discussed items > > (regarding the schema only - this is included to phase 1). > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations > > > > I think we can have the final discussion today (for phase 1) and > > in case no new remarks I will start the voting thread. > > > > With regards to AlterTopicRequest semantics. I agree with Jun, > > and I think it's my bad I focused on "multiple topics in one request". > > The same situation is possible in ProduceRequest, Fetch, TopicMetadata > > and we handle it naturally and in the most transparent way - we > > put all separate instructions into a map and thus silently ignore > > duplicates. > > This also makes Response part simple too - it's just a map > Topic->ErrorCode. > > I think we need to follow the same approach for Alter (and Create, > Delete) > > request. With this we add nothing new in terms of batch requests > > semantics. > > > > Thanks, > > Andrii Biletskyi >
