Joel, - DecreasePartitionNotAllowed. Yeah, that's kind of subcase of InvalidPartitions... But since client can always request topic metadata and check what exactly is was wrong with Partitions argument, I think, yes, we can remove DecreasePartitionNotAllowed and use InvalidPartitions instead. I'll update KIP accordingly if no objections.
- Questions regarding AdminClient. On one of the previous meetings I suggested we wrap up everything in terms of phase 1 (Wire Protocol and message semantics) so AdminClient is out of scope for now. I'll definitely take into account your remarks and suggestions but would rather wait until I finish phase 1 because I believe answers may change by that time. - Yes, correct. Any broker from the cluster will be able to handle Admin requests thus there is no need to add controller discovery info. Maybe it will be part of some separate KIP, as mentioned in KAFKA-1367. Thanks, Andrii Biletskyi On Thu, May 14, 2015 at 1:31 AM, 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 >
