Add DockerHub implementation for send_tags

[absoludity]

Description of the change

Adds the implementation for retrieving and sending tags for dockerhub repositories.

Benefits

Enables an initial integration to be tested.

Possible drawbacks

Applicable issues

• ref Implementation of OCI-Catalog gRPC micro-service #6263

Additional information

IRL test:

grpcurl -plaintext -proto ./proto/ocicatalog.proto -d '{ "repository": {"registry": "registry-1.docker.io", "namespace": "bitnamicharts", "name": "zookeeper" }}' 0.0.0.0:50001 ocicatalog.OCICatalog.ListTagsForRepository
{
  "name": "11.4.10"
}
{
  "name": "11.4.9"
}
{
  "name": "11.4.8"
}
{
  "name": "11.4.7"
}
{
  "name": "11.4.6"
}
{
  "name": "11.4.5"
}
{
  "name": "11.4.4"
}
{
  "name": "11.4.3"
}
{
  "name": "11.4.2"
}
{
  "name": "11.4.1"
}
{
  "name": "11.3.2"
}
{
  "name": "11.3.1"
}
{
  "name": "11.2.1"
}
{
  "name": "11.1.6"
}
{
  "name": "11.1.5"
}
{
  "name": "11.1.4"
}
{
  "name": "11.1.3"
}
{
  "name": "11.1.2"
}
{
  "name": "11.1.1"
}
{
  "name": "11.0.3"
}
{
  "name": "11.0.2"
}
{
  "name": "11.0.1"
}
{
  "name": "11.0.0"
}
{
  "name": "10.2.5"
}
{
  "name": "10.2.4"
}
{
  "name": "10.2.3"
}

[netlify]

✅ Deploy Preview for kubeapps-dev ready!

Name	Link
🔨 Latest commit	0add7d4
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/64d2a694b9e5a100094b7cb0
😎 Deploy Preview	https://deploy-preview-6580--kubeapps-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[antgamdia]

Thanks!

[antgamdia]

Just to confirm, are we only fetching (DEFAULT_PAGE_SIZE=100) elements for now, aren't we? I mean, there I don't see any pagination logic here. It seems Docker is using a Link header to let the client know about the next page (source), but we are not using it at the moment. No?

[absoludity]

That's just the current default pagesize for the requests we make to dockerhub (ie. how big are the batches that we request), so will affect performance only (number of requests required to exhaust the result). It's not limiting how many results we get at all (ie. if I set this to 10, then the loop will fetch the results in batches of 10).

The gRPC API that we provide streams the result back, so no pagination required.

[antgamdia]

For what is worth, (I guess you already know it, but just in case), here is the "official" (albeit tagged as experimental) DockerHub client: https://github.com/docker/hub-tool/blob/main/pkg/hub/tags.go#L61

[absoludity]

Yeah, as you can see in their (go) client, they need to collect all the page results (appending to the array) before returning the result. In our case, we're wanting to stream the results back (via gRPC stream) while they're collected, which is why I'm using these send_tags and send_repositories, to show the results down a channel (which we can buffer as needed) and continue fetching.

BTW: interesting to see they use the same default page size :)

[antgamdia]

Neat! Thanks for the explanation!

[antgamdia]

Ah - reading it twice, perhaps this is the pagination logic? If so, I would add some comments just for our future ourselves to understand 😅

[absoludity]

This is us using the pagination of the dockerhub API, yes - requesting the next page if response.next is defined. I'll add a comment to that effect.

[antgamdia]

Not now, but given the DockerHub rate limits, perhaps it is worthwhile adding sth like: https://crates.io/crates/governor for better handling it on the client side.

[absoludity]

Yeah, that'd be great to add in the future if we find we're hitting rate limits (I'll be testing this using the bitnami catalog, which is probably on the larger side of OCI helm registries).