Some more refactoring of storage #1525
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a significant refactoring of the storage handling logic. The new Storage struct in crates/lib/src/store now acts as a central point for accessing different storage backends like ostree and the container image store, improving encapsulation by removing the Deref implementation and introducing explicit accessors. The imgstorage module has been renamed to podstorage and its Storage struct to CStorage for clarity. These changes have been propagated consistently across the codebase. The review identified one minor issue with redundant code. Overall, this is a good refactoring that improves the code structure.
cgwalters
force-pushed
the
store-no-deref
branch
from
b1d231a to
f64dbef
Compare
To make clearer what it is vs the other two storage types. Signed-off-by: Colin Walters <[email protected]>
The goal here is to make all three types of storage effectively equal peers. Signed-off-by: Colin Walters <[email protected]>
This was a copy-pasteo from the ostree bits. Signed-off-by: Colin Walters <[email protected]>
It's just way too confusing we have two structs called `Storage`. I'm going to rename one of them after this. But as prep for that, switch to dynamically initialzing the containers-storage version from the main Storage. Signed-off-by: Colin Walters <[email protected]>
Previously we had two different `Storage` structs, this ensures that the main one is primary and `CStorage` is secondary. This should be less confusing. Signed-off-by: Colin Walters <[email protected]>
Naming things is hard, but as of right now since this storage instance doesn't hold the booted host, let's call it `podstorage` to make clear is association and purpose in being used by podman and related tools. Signed-off-by: Colin Walters <[email protected]>
cgwalters
force-pushed
the
store-no-deref
branch
from
f64dbef to
a99294f
Compare
|
So, if I understand correctly, we want |
That said, the more I think about things the more I feel what will make sense is to eventually aim for truly "unified storage" where we always pull bootable host containers into the containers-storage instance, and then copy from there into composefs or so. It'd give us a decent mix of the advantages of both. |
Update according to API changes introduced in bootc-dev#1525 Signed-off-by: Johan-Liebert1 <[email protected]>
Update according to API changes introduced in bootc-dev#1525 Signed-off-by: Johan-Liebert1 <[email protected]>
Update according to API changes introduced in bootc-dev#1525 Signed-off-by: Johan-Liebert1 <[email protected]>
No description provided.