Totally agree with the priorities, and I'm actually not even advocating the
alternative I through out. I think, ultimately, the connector developer is
the one who has to support compatibility, though, irrespective of the
mechanism. So I guess it is really just a question of whether it is easier
for
I see our "make life easy" priorities as follows: users > connector
developers > core copycat developers.
In this case I think that best user experience will be consistent behavior
for all copycat connectors, so they'll know what to expect during upgrades.
I'm not sure how much we can enforce from
Yeah I meant this purely as an approach for the connectors themselves to
implement not that we would automatically suppress configs in the
framework.
-Jay
On Fri, Aug 14, 2015 at 7:48 PM, Gwen Shapira wrote:
> The "ignore new configs" plan is good, IMO. I just don't know if its
> feasible in cu
The "ignore new configs" plan is good, IMO. I just don't know if its
feasible in current Copycat:
I'm not sure CC can ignore configuration on the connector behalf. Also,
this is something we will want to log very clearly and I'm not sure this is
doable outside the connector.
Regarding complex impl
I think this is a great area to think about.
What about the simpler informal scheme of just having cc ignore config it
doesn't know about and instructing connector developers to maintain
compatibility when renaming params (i.e. support both old and new) as we do
for Kafka config.
The steps would
Yes, I think that makes sense. As I see it, the tradeoffs are:
1. Complexity - adding these APIs increases the number of things connector
developers need to implement just to get started. In a lot of cases, the
first version of a connector might literally only have some connection
string as a sett
Hi Team Kafka,
This may be a slightly premature discussion, but forgetting about upgrades
is a newbie mistake I'd like us to avoid :)
So, we have connector-plugins, and users use them to create
connector-instances. This requires some configuration - database connection
string, HDFS namenode, etc.
