-
Notifications
You must be signed in to change notification settings - Fork 779
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
[RFE] Source and Destination for shared storage #110
Comments
@runcom Sure, in principle, why not. We do need to make sure that we don’t duplicate the development work in projectatomic/atomic ; and to the extent extraction already exists there, is there an actual, current or expected, benefit to reimplementing it here? |
the benefit would be to move this functionality to containers/image so it will be used by other ppl in other project |
related containers/image issue containers/image#38 |
By following discussion in containers/image#38, I am Implementing |
@mtrmac My plan is to enable |
I am working on the idea of multiple share storages based on remote file systems. The basic idea is to have a local writable file system for creating and modifying images, but allow source images to be stored on multiple different file systems. For example you might setup storage on /var/lib/nfs/storage where the storage is shared as a read only mount from a remote NFS Store. I would figure the same would work for gluster. Then these stores could be used by buildah and CRI-O for running containers. I think we should stick to OverlayFS format for all of these file system storages to keep it simple. Now we could theoretically use a gluster share for the local storage, but this could be risky. |
Hi, would this feature allow for something like below -- efficiently downloading a set of related images so duplicate layers are not re-downloaded? Looking for a better alternative to a series of
|
Independently of the ”shared storage” plans, which may deal with this in a systematic way, the # Copies a large image built FROM mybaseimage:latest
# Downloads everything
$ skopeo copy docker://myregistry:5000/myimage:latest dir:/var/lib/derived-latest
# Hard-link all existing files into the destination for the other image. Trivially cheap.
$ cp -la /var/lib/derived-latest /var/lib/base-latest
# This should not have to re-download the layers for mybaseimage, since downloaded above
# … and it doesn't
$ skopeo copy docker://myregistry:5000/mybaseimage:latest dir:/var/lib/base-latest The downside is that |
@runcom @mtrmac @vrothberg Is this still something we want? |
@rhatdan Wasn’t there some kind of “additional stores” functionality added to c/storage? Note that the original request for “shared storage” came from you, so do we want this? :) |
Ok we will rely on additional stores for this. |
From kubernetes/kubernetes#26788 (comment)
Would be nice to support such a thing in skopeo itself as part of our types /cc @rhatdan
@mtrmac do you think it makes sense?
The text was updated successfully, but these errors were encountered: