-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
As a user, I would like to mirror images by architecture #1786
Comments
how flatpak images are different from any other images that were built for a specific arch? |
They are not different. I heard from Katello that this feature would be very useful for flatpak workflows. At the end of the day, standard container image workflows will benefit from it as well. |
I don't think it's a good idea to have partially synced manifest list. It will introduce additional complexity to already very complex sync pipeline we have. To compare this to push workflow, one cannot push just partial manifest list. If you really insist on this, then rest of arches can be synced with on-demand policy, so layers are not downloaded however objects like manifest, layers are still created and saved in db. Config layer will be downloaded anyway. I, however, do not fancy that idea since it anyway adds additional complexity in the logic, but this approach would be the middle ground. |
When it comes to partially synced manifest lists, what are we going to do with corrupted manifests or manifests larger than 4MB? |
whole manifest list will be skipped. |
Provide users with the option to sync only the relevant manifests they are concerned with, rather than all manifests from a manifest list. Users working with a single architecture should avoid unnecessary synchronization of irrelevant data. This scenario is particularly useful for Flatpak images.
This is not a duplicate of #1563.
The text was updated successfully, but these errors were encountered: