Hi Viktor, KIP-179's reassignPartitions() API already has a validateOnly() option. There's no technical barrier to adding similar options to the other state-changing APIs in that KIP, if people think it would be useful. Please comment to say this on the [DISCUSS] thread for the KIP though.
In general I think the admin tools (even those those currently without a --validate-only option) do a good job of validating their inputs, and that issuing an erroneous command (one that could be detected by --validate-only option) wouldn't crash a cluster. If tools given bad arguments can cause that kind of problem I think the first thing to do is fix the tool. That leaves the second motivation: > and the result of the command is what they really want. The consequences of running an admin command can be quite openended. For example, creating a new topic might result in the cluster being imbalanced, but it's impossible to know when you create the topic. Did you have in mind some specific tools and use cases which could be improved? Cheers, Tom On 1 September 2017 at 17:17, Viktor Somogyi <viktorsomo...@gmail.com> wrote: > Yea, I think we have to make a constraint that the dry-run is valid as far > as the environment doesn't change. > > Also I think too that we can dismiss reporting admin operations (like > --describe) as they won't be that useful and focus only on those which are > altering. > > (Hope I got your questions right :) ) > > On 1 Sep 2017 16:54, "Ted Yu" <yuzhih...@gmail.com> wrote: > > State change on broker side may be subject to various factors (network, > disk, etc). > > How would the dry-run report state change which is close to what actually > happens in non-dry-run mode ? > > Thanks > > On Fri, Sep 1, 2017 at 7:48 AM, Viktor Somogyi <viktorsomo...@gmail.com> > wrote: > > > Hi all, > > > > I've been working on creating a KIP for one of the jiras that aim to > > refactor the admin commands (KAFKA-3268 > > <https://issues.apache.org/jira/browse/KAFKA-3268> -> KAFKA-5722 > > <https://issues.apache.org/jira/browse/KAFKA-5722>) and I see that the > > KIPs > > related to these are still under discussion or voting (KIP-183 > > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-183+-+Change+ > > PreferredReplicaLeaderElectionCommand+to+use+AdminClient> > > and > > KIP-179 > > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-179+-+Change+ > > ReassignPartitionsCommand+to+use+AdminClient> > > ). > > > > Hence I'd like to raise the question separately whether it'd be useful to > > create a --dry-run option generally for every new admin command going > > forward. I think that this would be very useful for provisioning changes, > > especially if somebody wants to make sure they don't crash the prod > system > > with their change and the result of the command is what they really want. > > Furthermore automatic provisioning tools would also benefit from this. > > > > I imagine that in case of the dry-run the broker side wouldn't run the > > command but only provide the changed state in some form. For example the > > changed partitions in case of the partition reassignment tool or the > > altered topics in case of the config-commands tool, however the format > > really depends on the tool being used. > > > > What do you guys think? Would such an addition make sense? > > > > Regards, > > Viktor > > >
