-
Notifications
You must be signed in to change notification settings - Fork 4.5k
socat
gets more resources
#19953
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
socat
gets more resources
#19953
Conversation
@davinchia can you confirm that this file is what is used by Cloud, and we don't overwrite these values? |
@supertopher are there any worries about exhausting our cluster resources? |
airbyte-commons-worker/src/main/java/io/airbyte/workers/process/KubePodProcess.java
Outdated
Show resolved
Hide resolved
I think this is the pattern to add ENV configs? I also think we shouldn't add this to the OSS helm charts for now, sort of like how @davinchia once this is merged, I have no idea how to try our a change in the cloud repo... |
airbyte-config/config-models/src/main/java/io/airbyte/config/EnvConfigs.java
Show resolved
Hide resolved
airbyte-config/config-models/src/main/java/io/airbyte/config/EnvConfigs.java
Show resolved
Hide resolved
@evantahler yes pattern looks right and yes we shouldn't add to OSS Helm charts for now as we don't really want to expose this to OSS users yet. After merge we have to:
I'm PTO after today till Dec 18th so please reach out to @pmossman or @git-phu for help! |
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.
Evan, I'm going to approve. Feel free to merge after addressing the comments.
Merged with a red test - that's a connector base format error, will be solved by #20163 |
We currently only allocate 0.2 CPU shares to the socat processes, but we've observed that we are hitting that limit:
Rather than remove socat and enforce the same pod affinity for all the pods in the sync, lets start by simply throwing money at the problem!
Future work would be to adjust this dynamically as needed at runtime, or for only those syncs with "fast enough" sources