Address problem of missing pool in StoppedPools property #3352
Conversation
|
I just wanted to mention that maybe we should also handle the case (although less likely to be triggered) in |
|
There seems to be a bit of a bug in that, the pool is still started and fully running. If stratisd is stopped and restarted, the pool should appear in either stopped or started pools, but appears in neither. |
mulkieran
force-pushed
the
error-if-no-unlock-method
branch
from
a37ee64
to
379337c
Compare
|
There is a deeper question. By corrupting the devices in a specific way, we can engineer a state where the pool is fully set up, but when we restart Stratis the pool is placed in the stopped pools data structure. If we teardown the pool, we make it impossible to restart it. This is a deeper issue, I'll file a separate issue for that. |
|
@jbaublitz Whoops, I forgot the remark here: #3352 (comment) . Taking a look now. |
| self.internal.len(), | ||
| self.internal.values().map(|info| info.encryption_info()), | ||
| ) | ||
| .ok() | ||
| .map(|info| StoppedPoolInfo { | ||
| .unwrap_or({ |
There was a problem hiding this comment.
I don't think this does the right thing. Errors are only returned when they're a mixture of encrypted and unencrypted devices. I think this aspect of the code should be handled in engine/shared.rs in the gather methods. Gather takes a function as a parameter so it can likely be modified to calculate whether it's PoolEncryption::KeyDesc(MaybeInconsistent::Yes), etc.
There was a problem hiding this comment.
When the two arguments to gather_encryption_info are constructed, the iterator derived from internal.values() returns None in one place, so that the flattened length is less than the unflattened.
I think that what you're saying is that when the information is being gathered, it is possible to determine what is the encryption info on the devices w/ valid encryption info.
So, if all the devices w/ valid LUKS metadata are KeyDescription only, then you would like to see PoolEncryptionInfo::KeyDesc(MaybeInconsistent::Yes) rather than both showing inconsistent?
I think we can do that, but my own position is that in the general case where the LUKS info is actually missing because invalid, that information is not certainly known, so I decided to use the most confused value.
If all the devices had valid LUKS2 metadata, and each had a key description, but some key descriptions were different from others, then I would think that it would be appropriate to return
`PoolEncryptionInfo::KeyDesc(MaybeInconsistent::Yes), but it actually make more sent to me to return Both``` as I do here, in this situation.
| .filter_map(|(pool_uuid, map)| { | ||
| map.stopped_pool_info().map(|info| (*pool_uuid, info)) | ||
| }) | ||
| .map(|(pool_uuid, map)| (*pool_uuid, map.stopped_pool_info())) |
There was a problem hiding this comment.
This looks correct. It seems like we may have been only displaying encrypted pools in general for stopped pools, not just in the case of this bug!
If there is encryption info on some devices but not others, just assume maximum possible inconsistency in the encryption. Signed-off-by: mulhern <amulhern@redhat.com>
mulkieran
force-pushed
the
error-if-no-unlock-method
branch
from
e30e767
to
451b196
Compare
mulkieran
changed the title
|
I don't think that If exactly one element of the set and that is If two elements of the set, then something is inconsistent. Then feed the rest to the from method for PoolEncryptionInfo, as before. |
No description provided.