-
Notifications
You must be signed in to change notification settings - Fork 116
Composefs backend #1314
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
base: main
Are you sure you want to change the base?
Composefs backend #1314
Conversation
Done to facilitate the installation of a composefs repository to disk Signed-off-by: Pragyan Poudyal <[email protected]>
Signed-off-by: Pragyan Poudyal <[email protected]>
Signed-off-by: Pragyan Poudyal <[email protected]>
Signed-off-by: Pragyan Poudyal <[email protected]>
cd42079
to
b3d1952
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!!
.create_dir_all("composefs") | ||
.context("Creating dir 'composefs'")?; | ||
|
||
tracing::warn!("STATE: {state:#?}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend dbg!
for this type of stuff; it will build locally but not pass CI so it can't be accidentally merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I intend to remove all these logs. They were only for debugging purposes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep that makes sense, what I meant is that use dbg!
locally. (Or use tracing::debug!
and keep the tracing in there and just use the tracing selector to ensure you see what you want...we are really chatty with a big env RUST_LOG=debug
unfortunately today, mostly in container fetches)
@@ -1199,7 +1199,7 @@ async fn run_from_opt(opt: Opt) -> Result<()> { | |||
let fd = | |||
std::fs::File::open(&path).with_context(|| format!("Reading {path}"))?; | |||
let digest: fsverity::Sha256HashValue = fsverity::measure_verity(&fd)?; | |||
let digest = hex::encode(digest); | |||
let digest = digest.to_hex(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be squashed with the previous commit, and it may make sense to have a "bump composefs-rs" prep PR split out right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that makes sense. I'll put this in a separate PR
async fn install_to_filesystem_impl( | ||
state: &State, | ||
rootfs: &mut RootSetup, | ||
cleanup: Cleanup, | ||
composefs: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would make sense as part of state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was conflicted on where to put this. Thanks for the review. I'll add this to State
&imgstore, | ||
) | ||
.await?; | ||
tracing::warn!( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment re dbg!
or this one could also make sense as a tracing::debug!
that gets left in right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes. We can keep this one as debug
The branding here is a bit confusing because of course, bootc already uses composefs. Just the https://github.com/composefs/composefs/ version, and that is "indirectly" via ostree. Bigger picture I think what we're trying to aim for here primarily is "sealed" images right? In that case then, one thing I think would make sense is that we don't even have an option to install - we determine what to do by inspecting the container. It does of course make sense to eventually support unsealed images this way too...which will be extremely important for eventually migrating existing ostree systems. There's an enormous set of details there though. So my proposal in a nutshell:
|
A rough draft for installing and booting using
composefs-rs
. Current only works forinstall to-disk
viabootc install to-disk --composefs [options]
Issues:
continers-storage
, viz, #117. Needs some ironing out.composfs-rs
components, namelycomposfs-setup-root
I have a few logs being logged as warning, just for visibility. Will remove them when it's ready.
Same with
composefs-rs
patch incargo.toml