-
Notifications
You must be signed in to change notification settings - Fork 55
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
Add origin field to StratFilesystem #3516
Add origin field to StratFilesystem #3516
Conversation
f7af1d2
to
47c514e
Compare
Cockpit tests failed for commit 47c514e. @martinpitt, @jelly, @mvollmer please check. |
a5649a9
to
2ade7f5
Compare
We can not add an origin field without including the abllity to update the origin field in the case that a filesystem is removed and another filesystem has an origin field which points to that filesystem. So we must determine, before this PR is merged, what the rule is supposed to be. There are two possibilities:
|
fd9f226
to
7cf9692
Compare
We're best off setting the origin field to None. TODO: handle D-Bus signals. |
0524e0e
to
3973bfe
Compare
We may want to make the D-Bus property settable, for debugging purposes. |
b5e6e35
to
c0c2ee8
Compare
c0c2ee8
to
22b73b3
Compare
3adcd7f
to
00c8aba
Compare
rebased |
00c8aba
to
719a4dc
Compare
/packit test |
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've tested this with the changes from stratis-cli#1045 and I'm seeing all the behaviour I expect: for regular file systems the origin field is unset and for snapshots I get the UUID of the origin volume.
The only thing I was unsure of reading the patches was whether the value printed for the report should be "None" rather than "Not set" to be consistent with the CLI output for file systems with no origin, but looking at the rest of the report code this is consistent with what we report when size_limit
is not set so I think this is fine.
719a4dc
to
b202b11
Compare
b202b11
to
0202870
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.
Just a few code cleanliness comments, but overall I think this looks good.
let (name, fs) = self | ||
.get_filesystem_by_uuid(fs_uuid) | ||
.expect("Looked up above."); |
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 don't see any reason for this not to be inside the if changed ...
block. That would avoid looking it up if nothing has changed.
src/engine/sim_engine/pool.rs
Outdated
let snapshots: Vec<FilesystemUuid> = self | ||
.filesystems() | ||
.iter() | ||
.filter_map(|(_, u, fs)| { | ||
fs.origin() | ||
.and_then(|x| if removed.contains(&x) { Some(*u) } else { None }) | ||
}) | ||
.collect(); | ||
|
||
let mut updated_origins = vec![]; | ||
for sn_uuid in snapshots { | ||
if let Some((_, fs)) = self.filesystems.get_mut_by_uuid(sn_uuid) { | ||
if fs.unset_origin() { | ||
updated_origins.push(sn_uuid); | ||
} | ||
} | ||
} |
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 could all be collapsed into a single iterator using filesystems_mut()
for the iterator and fold()
at the end to collect the updated origins.
src/engine/types/actions.rs
Outdated
} | ||
} | ||
} | ||
|
||
impl Display for SetDeleteAction<FilesystemUuid> { | ||
impl<U> Display for SetDeleteAction<FilesystemUuid, U> { |
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 erring on the side of specificity is good for these impl
s so using FilesystemUuid
might be better. Otherwise, we have a frequent problem of overlapping impls. That would also allow us to add to the log message indicating what UUIDs had their origin updated.
0202870
to
1994592
Compare
@jbaublitz I think it is ready now. |
Signed-off-by: mulhern <[email protected]>
0c3f9d5
to
82048fb
Compare
rebased |
Signed-off-by: mulhern <[email protected]>
Expose on D-Bus and store in metadata Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
82048fb
to
faa4822
Compare
squashed... |
Closes #3515