Hello, Igor, long time no speak!
I think I understand your plight here, and we did come up with a workaround several years ago to pre-populate images on a remote rack controller before the rack itself was fully synchronized via the region controller’s point of view.
In this case however, in 3.5 and later, the images are no longer stored in the DB as they were previously, they’re stored on the filesystem itself.
For bootloader images, those are fetched on-demand from each machine via the region controller. They are not cached at all on the rack controller(s).
For non-bootloader images (eg: your custom images you would normally sync and upload to the region), those are cached on the rack controller in its own local cache. If the image is already present in the local rack controller cache, it’s served from there.
If it’s not already present when a machine asks for it, it’s fetched from the region controller, cached on the rack controller (in the rack’s filesystem, not the DB), and served from there. Any machine after the first ‘cold’ fetch of that image, will then pick up the copy that is now local to the rack in its cache.
What I think you’re asking for sounds the same as the request from back in 2021, where you want to ‘seed’ the rack controller with all of the images it might need, before that rack is fully joined to the region, and before the very first machine on that rack requests an image.
Is that a correct assumption?
You could, if you wanted to discuss specifics, file a case with the Support team, and we can engage more fully “internally”. We’re limited as to what we can share about your environment and its needs out here in the public Discourse forum.
Hope that helps!