THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
There is no new public interface, however the behavior of the create connector api will change insomuch as some connector names that previously worked will now not be accepted anymore when creating new connectors. This may break deployment scripts for a few people, so we should definitely announce this as a breaking change, not sure if a full deprecation cycle makes sense, but since this will definitely be post 1.0 I guess it might be a good ideaa little bit.
Following implementation of this KIP, leading and trailing whitespaces in connector names will be trimmed before the connector is created. In the response to the create request the updated name will be reflected. See the following table for a few examples:
| Original name | Trimmed name | Comment |
|---|---|---|
| " test" | "test" | |
| "test " | "test" | |
| " test " | "test" | |
| " " | "" | Will be rejected as empty connector name! |
This is a change to current behavior, as today when sending a create connector request the connector will be created with the specified name or the request will fail, names are not changed by Connect. However, requests containing whitespaces would fail in the current version (fixed in KAFKA-4827) - so it could be assumed that not many people rely on connectors containing whitespaces in the name at all.
See Migration plan and compatibility for scenarios that might be influenced by this change in behavior.
Migration plan and compatibility
...
Since no characters are restricted nothing that previously worked should break based on this KIP. Connectors with an empty name were broken before and could not be deleted anyway, so there is no reason to half-support these any further. It is however a change in behavior to reject these.
There is however one scenario that is affected by this change:
If an external system is used to manage connectors, the change in connector names could potentially cause this system not to find deployed connectors anymore - if their names contain trailing or leading whitespaces!
- Create connector: "test " -> Connector gets created (request fails though, due to KAFKA-4827)
- Query status of connector: "test " -> Fails as the connector was created with the name "test"
There are two points worth noting in this scenario though:
- The system managing the connectors would have to completely ignore the response from connect to the first request, as this would return an error in the current version and it should not have assumed that the connector has been created anyway.
- Following the fix for KAFKA-4827 being merged the request would be successful, but contain the updated name for the created connector, so there would be an easy check to update the name used.
Based on the above points I would consider this a fringe scenario that should not impact a significant number of people (to be honest, I'd be surprised if anyone is impacted at all). Additionally I can't come up with a valid reason to use trailing or leading whitespaces in connector namesThe only scenario that I can come up with is an automated deployment of connectors containing leading or trailing whitespaces that later expects being able to query configuration and status of these connectors under that connector name. I think adding a note to this effect to the release notes should suffice (if that, one might argue that this is a fringe case).
Rejected alternatives
Initially the proposal was to reject a number of characters as illegal in connector names based on a whitelist or blacklist. However following discussions on the mailinglist it was agreed that we can be very generous in allowing characters in connector names as long as all rest requests are properly url-encoded.
...