Summary
User is facing rate limiting issues when pulling images for Airbyte in Kubernetes deploy. Most issues resolved with 1.2.0 release and global image registry setting, but two images (airbyte/source-declarative-manifest:5.17 and airbyte/source-jira:3.2.1) are hardcoded to pull from Airbyte Docker Hub, causing instance to be blocked from running checks or syncing Jira data. User is seeking a fix for this issue.
Question
Hi all! I’ve been facing a bunch of issues around rate limiting when pulling images for my kubernetes deploy of Airbyte. However with the release of 1.2.0 and the use of the global image registry setting, most of my issues are now resolved.
With that I have two images in particular that just appear to be hard coded to pull from the airbyte docker hub repo airbyte/source-declarative-manifest:5.17 and airbyte/source-jira:3.2.1. So my instance is currently blocked from running any checks or sync my Jira data.
Has anyone else experienced this or know of a fix?
FYI I am deploying via helm.
This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. Click here if you want
to access the original thread.
Join the conversation on Slack
["rate-limiting", "kubernetes-deploy", "airbyte-1.2.0", "global-image-registry", "hardcoded-images", "docker-hub", "helm", "jira-data"]
Sorry for the trouble here. I will bring this up with the team and try and get this sorted out. Likely it will be a fix in the next release.
ok thanks for the response! is there an issue we can track?
If you have any luck with a workaround please let me know! 
I’m having a similar issue, but looks like first i need to upgrade to v1 first for the global setting. But it still looks like airbyte/source-declarative-manifest for the custom connector builder is hard coded.
<@U07C8CCC68Y> You think you could point us into the right direction? Is this a matter of waiting for a minor version release or should we invest the time to try to make a change to the source code.
Issue: All images need to be pulled from our private ECR repo.
Thanks for the reply! I found a workaround with Jira, with adding a custom docker connector pointing to the Jira image in my repo.
However I run a lot of custom connections so declarative-manifest being hard coded is really going to cause an issue for me. I seem to be stuck in a perpetual loop of being rate limited at the moment too.
Nice! Yes, if I don’t find a work around for the declarative-manifest the customer low-code connector builder feature will be useable for me and may even think about going the Dagster + PyAirbyte route instead.
<@U07C8CCC68Y> any updates from the team on this? Is there estimated release version you think this fix would be implemented in?
There is work in progress, but the change is not likely to land until the middle of December
Will this set the repo for all connectors including the market place such that we can mirror the ones we need to our ECR in aws and pull from there?
Middle of December would be great if possible
yes, if you configure a private registry, it is “all or nothing” at the moment.
The work has been started but with the holidays in the US things are slow going right now.