[feature] Possible Way To Ignore Hauler Store Sync Errors?

irishgordo commented 1 month ago

Is this Feature/Enhancement related to an Existing Problem? If so, please describe:

First and foremost - big thanks to everyone contributing to this project - Hauler is awesome and really is the swiss army knife of airgap!

I was wondering if there could be a possibility to allow more flexibility in hauler store sync via a manifest in the form of:

increasing the number of retries per image
ignoring possible failures

In a Jenkins pipeline I recently caught:

        "\u001b[90m2024-10-25 23:19:09\u001b[0m \u001b[32mINF\u001b[0m adding 'image' [mystery-registry-somewhere-neat.com/rancher/mirrored-prometheus-operator-prometheus-operator:v0.72.0] to the store",

        "\u001b[90m2024-10-25 23:19:14\u001b[0m \u001b[32mINF\u001b[0m successfully added 'image' [mystery-registry-somewhere-neat.com/rancher/mirrored-prometheus-operator-prometheus-operator:v0.72.0]",

        "\u001b[90m2024-10-25 23:19:14\u001b[0m \u001b[32mINF\u001b[0m adding 'image' [mystery-registry-somewhere-neat.com/rancher/mirrored-prometheus-prometheus:v2.50.1] to the store",

        "\u001b[90m2024-10-25 23:19:19\u001b[0m \u001b[32mINF\u001b[0m successfully added 'image' [mystery-registry-somewhere-neat.com/rancher/mirrored-prometheus-prometheus:v2.50.1]",

        "\u001b[90m2024-10-25 23:19:19\u001b[0m \u001b[32mINF\u001b[0m adding 'image' [mystery-registry-somewhere-neat.com/rancher/mirrored-prometheus-windows-exporter:0.25.1] to the store",

        "\u001b[90m2024-10-25 23:19:21\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m Error: unable to find an entity for linux/amd64",

        "\u001b[90m2024-10-25 23:19:21\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m main.go:74: error during command execution: unable to find an entity for linux/amd64",

        "\u001b[90m2024-10-25 23:19:21\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m error (attempt 1/3): exit status 1",

        "\u001b[90m2024-10-25 23:19:29\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m Error: unable to find an entity for linux/amd64",

        "\u001b[90m2024-10-25 23:19:29\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m main.go:74: error during command execution: unable to find an entity for linux/amd64",

        "\u001b[90m2024-10-25 23:19:29\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m error (attempt 2/3): exit status 1",

        "\u001b[90m2024-10-25 23:19:36\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m Error: unable to find an entity for linux/amd64",

        "\u001b[90m2024-10-25 23:19:36\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m main.go:74: error during command execution: unable to find an entity for linux/amd64",

        "\u001b[90m2024-10-25 23:19:36\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m error (attempt 3/3): exit status 1",

        "\u001b[90m2024-10-25 23:19:36\u001b[0m \u001b[1m\u001b[31mERR\u001b[0m\u001b[0m operation failed after 3 attempts"

And from that I do gather that it started to fall apart on sync because linux/amd64 as a platform didn't exist for whatever image.

In our current use case we're kinda wrapped around elements in a few ways:

we may not be auditing a laundry list of images that are published via txt file, instead dynamically grabbing them, then building a manifest.yaml file w/ a respective name to perform a sync
we may be dealing with a registry that may or may not rate-limit us

So I guess it's sort of two fold:

is there a way to possibly ignore image failures upon store sync or maybe to allow them to attempt to grab "linux/amd64" but if that's not available, like fallback to the default of whatever is available?
is there a way to increase the attempt per image? or also possibly incoporate some like exponential backoff logic or something if there is a chance you might be rate-limited in grabbing those images from whatever registry that might be?

Describe Proposed Solution(s): Maybe extra metadata.annotations for the Image resource that do extra things?

Describe Possible Alternatives: Not really implementing this and leaving it more to the end user's responsibility to juggle source & platform compatibility.

Additional Context: Again, this project is awesome! Ty to all the contributors! Also, I'm on an older version of Hauler:

 __    __       ___       __    __   __       _______ .______
|  |  |  |     /   \     |  |  |  | |  |     |   ____||   _  \
|  |__|  |    /  ^  \    |  |  |  | |  |     |  |__   |  |_)  |
|   __   |   /  /_\  \   |  |  |  | |  |     |   __|  |      /
|  |  |  |  /  _____  \  |  `--'  | |  `----.|  |____ |  |\  \----.
|__|  |__| /__/     \__\  \______/  |_______||_______|| _| `._____|
hauler: Airgap Swiss Army Knife

GitVersion:    1.0.4
GitCommit:     05e67bc
GitTreeState:  clean
BuildDate:     2024-06-26T03:29:02Z
GoVersion:     go1.21.11
Compiler:      gc
Platform:      linux/amd64

zackbradys commented 2 weeks ago

Hey @irishgordo! Apologies for taking so long to get back to you. Thanks for the write up and glad to hear that hauler has been working well for you and your use cases!!

We've been tracking a few of these ideas/concerns/issues and made some changes that should help you in the recent release of v1.1.0 and will have more changes/improvements in the next patch release of v1.1.1

zackbradys commented 5 days ago

partially similar to Issue https://github.com/hauler-dev/hauler/issues/323...

irishgordo commented 14 hours ago

Hi @zackbradys 👋 - thanks for that mention :)

I'll definitely shift over to using a more recent version of Hauler soon too.

hauler-dev / hauler

[feature] Possible Way To Ignore Hauler Store Sync Errors? #349