[DOCS] Kafka Connect and Mirror Maker upgrades, plus minor style edits #48
Conversation
|
Should this refer to "Kafka Connect connectors" rather than "Kafka Connect"? |
| @@ -6,7 +6,7 @@ | |||
|
|
|||
| = Strategies for upgrading clients | |||
|
|
|||
| The best approach to upgrading your client applications (including Kafka Connect connectors) depends on your particular circumstances. | |||
| The best approach to upgrading your client applications (producers, consumers, Kafka Connect, and MirrorMaker) depends on your particular circumstances. | |||
|
@laidan6000 Well, it depends what do you want to update. In your text IMHO Kafka Connect is correct. However, from the title of this PR, I expected that this will have the upgrade guide for Kafka Connect and Kafka Mirror Maker. Which it doesn't. Connect and Mirror maker should really have their own upgrade procedures. |
| @@ -6,7 +6,7 @@ | |||
|
|
|||
| = Configuring Kafka brokers to use the new message format version | |||
|
|
|||
| When client applications have been upgraded, you can update the Kafka brokers to use the new message format version (2.1). | |||
| When client applications (producers, consumers, Kafka Connect, and MirrorMaker) have been upgraded, you can update the Kafka brokers to use the new message format version (2.1). | |||
There was a problem hiding this comment.
Should we use an attribute for this "new message format version", because it's likely to change again in the future and we'll likely forget to update to update all the places it has been used.
There was a problem hiding this comment.
I suppose we'd also need an attribute for the inter-broker protocol versions. Given time constraints, I'd rather handle this when we make any necessary changes to this chapter to align with the next downstream release.
|
@scholzj - Regarding having separate procedures, @tombentley is of the view that Kafka Connect and Mirror Maker do not need separate procedures. We should just highlight that they are types of clients. |
It's different on OCP, of course, because we're providing the operators for these, so they warrant procedures imho, but on RHEL I don't think it's really necessary. |
|
TBH, I do not agree with that. i think we should have a procedure for that on both. Even if it would be just a stupid procedure which would say to change the For Mirror Maker it might also tell them how to configure different versions on each side. For Connect it should probably give some advice on what to do with connectors. |
Co-Authored-By: laidan6000 <dlaing@redhat.com>
|
Following Jakub's review, I've added a new procedure named "Upgrading Kafka Connect to AMQ Streams 1.1.0". This is mainly based on the existing procedure, "Upgrading Kafka brokers to AMQ Streams 1.1.0". Decided not to have a standalone procedure for MirrorMaker upgrades because we are lacking in any other documentation on MirrorMaker. Please review the changes on my file share: http://file.rdu.redhat.com/~dlaing/#assembly-upgrade-1-1-0-str |
Co-Authored-By: laidan6000 <dlaing@redhat.com>
This pull request clarifies that Kafka Connect and Mirror Maker are just client applications and should be upgraded to the new Kafka version along with other clients. It also makes a few style and wording changes.
You can view the staged documentation on my file share: http://file.rdu.redhat.com/~dlaing/#assembly-upgrade-1-1-0-str