Totally agree about getting things right in the first round. In addition, I believe that it is important that names of our tools will describe what the tools do as accurately as possible - this improves usability. Therefore, we should shift the discussion to whether the tool should handle all offsets or just source offsets. The name of the tool will naturally be derived from the decision of what the tool will do.
Now that it is an important discussion about functionality and not bike-shedding about names: I am strongly supportive of duplicating functionality and having a Connect tool that handles all aspects of resetting connector state. As you said, the specifics of how Connect manages its offsets are an implementation details that I don't expect users to know and care about. I also want to point out that the Streams reset tool already duplicates some functionality and this doesn't seem to be a problem because the context (Streams) is well defined. Gwen On Tue, Sep 12, 2017 at 7:30 PM Ewen Cheslack-Postava <e...@confluent.io> wrote: > I don't think it's bikeshedding and it is a fair question. I try to avoid > that because this is part of the point of KIPs -- avoid extra pain around > usability, documentation, maintenance, and compatibility and deprecation by > just trying to get things right on the first go around. > > It's obviously just my preference, but I would rather name it what we > ultimately want and document limitations while we fill in the gaps. This is > a case where I really don't know whether we'll want to extend it to > effectively duplicate some of the behavior of an existing tool for the sake > of consistency, so I raised it for discussion. > > -Ewen > > On Tue, Sep 12, 2017 at 10:51 AM, Gwen Shapira <g...@confluent.io> wrote: > > > > > > > > > > > * re: naming, can we avoid including 'source' in the command name? > even > > > if > > > > that's all it supports today, I don't think we want to restrict it. > > While > > > > we only *require* this for source offsets, I think for users it will, > > > > long-term, be way more natural to consider connect offsets generally > > and > > > > not need to know how to drop down to consumer offsets for sink > > > connectors. > > > > In fact, in an ideal world, many users/operators may not even > > > *understand* > > > > consumer offsets deeply while still being generally familiar with > > connect > > > > offsets. We can always include an error message for now if they try > to > > do > > > > something with a sink connector (which we presumably need to detect > > > anyway > > > > to correctly handle source connectors). > > > > > > > > > > ack > > > > > > > > Sorry about bikeshedding, but: > > I think a general name for something that has limited functionality is > very > > confusing (and we've seen this play out before). Why not name the tool to > > describe what it does and change its name if we change the functionality? > > > > > > > > > > >
