Closed milan-zededa closed 1 day ago
@deitch We are still hitting the docker pull limit, even if we login into dockerhub under the lfedge user.
Could it be that this login does not take effect when we run docker build
?
See: https://github.com/lf-edge/eve/actions/runs/9780260059/job/27001499185?pr=4050#step:9:46
I don't know how this pull works internally:
#3 [internal] load metadata for docker.io/library/golang:1.20.1-alpine
@deitch We are still hitting the docker pull limit, even if we login into dockerhub under the lfedge user. Could it be that this login does not take effect when we run
docker build
? See: https://github.com/lf-edge/eve/actions/runs/9780260059/job/27001499185?pr=4050#step:9:46I don't know how this pull works internally:
#3 [internal] load metadata for docker.io/library/golang:1.20.1-alpine
The docker login is working. Just re-ran the job and the build and it worked fine. Also, there is docker logout in the post build section that confirms the login. It's just that we are hitting the limit even with an authenticated user.
It's just that we are hitting the limit even with an authenticated user
It could be that our account is hitting the limits. I find it interesting, as the complaint was about the library/golang
an official Docker image; I didn't think those had pull limits, but clearly I was wrong. And I just checked in the forum and see something similar.
So login doesn't solve it, unless we upgrade the account. That probably is the easiest path.
Alternatives:
Others?
It's just that we are hitting the limit even with an authenticated user
It could be that our account is hitting the limits. I find it interesting, as the complaint was about the
library/golang
an official Docker image; I didn't think those had pull limits, but clearly I was wrong. And I just checked in the forum and see something similar.So login doesn't solve it, unless we upgrade the account. That probably is the easiest path.
Alternatives:
- pay for a real account - a few tens of $USD per month is probably the cheapest option
- mirror the images - requires changing all of the Dockerfile and similar to reference a local registry, and find somewhere to run it; not the simplest solution
- proxy read-through mirror - a little bit easier, as it avoids renaming, but we still need to figure out where to run it
Others?
I think the first solution is the most cost-effective in terms of both price and effort.
FWIW, maybe we should also check with LF Edge if DockerHub can upgrade the account for free, since LF is a big foundation. Docker does sponsor open-source projects: Docker Open Source Program.
Others?
Torrentz!!! ;-) --> https://github.com/uber/kraken
Smoke tests couldn't run because of some github workflow issue:
Run actions/download-artifact@v4
Downloading single artifact
Error: Unable to download artifact(s): Not Found
I got this even after re-run. The rest looks OK. I'm going to merge this so that it can be backported to 12.0 LTS.
I think the first solution is the most cost-effective in terms of both price and effort.
Working on it.
When cellular network config changes, it may take few seconds for the wwan microservice and the modem to apply the new config. NIM microservice should wait for the wwan config to be fully applied when cellular connectivity is used for management and ethernet is not available. Otherwise, it may determine the connectivity as not working and failover to the previous config too fast, not giving the modem the chance to connect with the latest config.
Also fixed in this commit is the
Equal()
method forCellularAccessPoint
. It used to compare also timestamp insideErrorAndTime
which may change even if there is no actual config change. As a result, wwan microservice would trigger re-connection even when there was no config change to apply. This fix is in pillar and will be propagated intopkg/wwan/mmagent
in the next commit (withgo get
) once this one is merged.