Open tfadeyi opened 3 years ago
This is a tricky one. There is a couple things going on here.
First thing I noticed was that we are not handling paging properly in most/all our clients. I will create another issue for that.
Next, version-checker is doing a bad job of being architecture aware, leading to the issue above where it picks the wrong architecture as the latest when they both have the same timestamp. To fix this correctly, we should create a node controller. This will expose a map[string]struct{OS, Arch} which should be passed down into our searcher. The searcher can then be aware of which architecture and OS to be filtering for, when getting the latest. An override option may be appropriate here, but let's leave that for later. We should update the metrics to include the os and arch as labels.
The next thing to fix is the clients which do not expose the arch and OS of image tags available. In these cases, we will likely need to swap out the native API for our first class supported clients, in favour of using the fallback generic docker API, which does support getting this information. We will likely need to do a bit of a dance in terms of permissions, in that we get a valid access token/username/password using the native client first, then passing them on correctly to the generic docker client. We shouldn't expect any config API changes.
Lastly, we need to fix the issue of the "composite hashes". When using an image in Kubernetes which has the tag of "", or "latest", and the selected tag that docker pulls is a multi-architecture image, the reported image SHA as part of the "imageID", will be the "composite hash". This means that, the reported image hash will be the hash of the full json payload (denoted in the HTTP header as DOCKER-IMAGE-DIGEST), rather than the particular image digest. To fix this, we should include a "CompositeHash" field as part of the "ImageTag" struct which includes this value, along with the image SHA. The searcher then need to be aware of whether it should compare against the raw SHA value, or the CompositeHash value. Depending on the client, it may never report a composite hash in these cases, and should be tested. If this is the case, we can save some KB and make the CompositeHash field a *string, making the searcher fall back to SHA when nil.
This issue has been automatically marked as stale because it has not had any activity in the last 90 days. It will be closed if no further activity occurs. Thank you for your contributions.
What happened? When I was running version-checker on KIND (amd64), the latest image version reported for the following container
docker.io/ealen/echo-server:latest
was3f390e3cb38a1bb7a5169b27ae56285335ffede3cf334156e4d826173ce54ae5
, for arm/v6, instead of the tag for amd64 or the tag used for the manifests collectionsha256:3419f7cf35d10c9096ce359df762283ccfa7af12095f9be51542566bef8e9034
which is the actual ID assigned to the container when using:latest
.Logs Echo Image Manifests and digests:
vc metrics:
The targeted pod: