-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(dev): Upgrade kafka and zookeeper to support Apple M1 #28574
Conversation
@@ -162,7 +162,7 @@ runs: | |||
--name sentry_zookeeper \ | |||
-d --network host \ | |||
-e ZOOKEEPER_CLIENT_PORT=2181 \ | |||
confluentinc/cp-zookeeper:4.1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems the CI was running an older version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What version do we run in production?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we run 4.1.2-3 and version 3.4.11 for zookeeper.
Should I make the CI test against those versions?
As curiosity, we run a range of versions across the org: https://github.com/search?q=org%3Agetsentry+cp-kafka&type=code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we should have CI match production, let's leave comments here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@billyvg I've discovered that version of zookeeper we use in production is no longer available on Docker hub, thus, we cannot match the versions between CI and production.
FYI, this part of the PR is completely unnecessary to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Asked about the versions picked in #20543 (review)
I tried getting rid of zookeeper but it got complicated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also change these in getsentry
@@ -162,7 +162,7 @@ runs: | |||
--name sentry_zookeeper \ | |||
-d --network host \ | |||
-e ZOOKEEPER_CLIENT_PORT=2181 \ | |||
confluentinc/cp-zookeeper:4.1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we should have CI match production, let's leave comments here
@@ -1724,15 +1724,15 @@ def build_cdc_postgres_init_db_volume(settings): | |||
), | |||
"zookeeper": lambda settings, options: ( | |||
{ | |||
"image": "confluentinc/cp-zookeeper:5.1.2", | |||
"image": "confluentinc/cp-zookeeper:6.2.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we leave comments here about the versions and why it differs from CI/prod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
There's no changes required on |
When developing locally with Docker today, I ran into a new issue of sentry_kafka and sentry_zookeeper docker containers continually crashing and restarting. The error logs match confluentinc/cp-docker-images#883. I believe this is due to updating to 6.2.0 from 5.1.2 in conf/server.py. Reverting these two lines solves the issue locally. |
If this doesn't get reverted today, I will look into fixing it tomorrow. Are there any tests that should have caught this? What tests could catch such a regression? |
…28574)" This reverts commit b4bfb00. It seems to cause the images to restart (see [comment](#28574 (comment))).
I created #28672 in case someone wants to revert this change while I'm off today. |
When we [upgraded the kafka and zookeeper images we use][1], we did not update the volume to use the full path (as the [instructions indicate][2]), thus, started to see this error: > Command [/usr/local/bin/dub path /var/lib/kafka/data writable] FAILED ! This change adds the full path. [1]: #28574 [2]: https://docs.confluent.io/platform/current/installation/docker/operations/external-volumes.html#data-volumes-for-kafka-and-zk
There's a fix in #28724 |
When we [upgraded the kafka and zookeeper images we use][1], we did not update the volume to use the full path (as the [instructions indicate][2]), thus, started to see this error: > Command [/usr/local/bin/dub path /var/lib/kafka/data writable] FAILED ! This change adds the full path. [1]: #28574 [2]: https://docs.confluent.io/platform/current/installation/docker/operations/external-volumes.html#data-volumes-for-kafka-and-zk
…28574)" (#28672) This reverts commit b4bfb00. Originally (see [originally reported issue](#28574 (comment))), instead of reverting my change, I landed a fix that only seems to work on Apple M1 (see fix #28724). Nevertheless, It seems that the *Intel* images would still fail with the same error (see issue #29022) with: > Command [/usr/local/bin/dub path /var/lib/kafka/data writable] FAILED ! Let's revert it and I will try again later. Fixes #29022
This version of zookeper does not throw qemu panics on Apple's M1.
See issue: confluentinc/kafka-images#80 (comment)