storage: set backlinks only if other post-init methods succeed #2138
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When creating a fsobj, e.g., a partition, we automatically modify associated fsobj-s (e.g., the underlying disk) to make them aware of the newly created object. We do this through the use of backlinks and more specifically the function _set_backlinks. Currently, this function is automatically called first when entering the fsobj's __post_init__ method. If a fsobj defines its own __post_init__ method (let's called it user-defined), it gets called after _set_backlinks. This is usually fine. However if the user-defined __post_init__ raises an exception, we end up with backlinks referencing an object that was not successfully initialized. This is what happens with the Partition fsobj. In its user-defined __post_init__, we determine the partition number by looking at the underlying disk. If the number could not be determined (because there is no more number available), we raise an exception "Exceeded number of available partitions". However, at this point, the underlying disk is already aware of the new partition - through the use of backlinks. Iterating over the list of partitions will then raise a TypeError when trying to use partition.number - which has not been successfully assigned. Fixed by calling _set_backlinks after the user-defined __post_init__, so that we only set the backlinks on success. refs LP: #2095159 Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
dbungert
approved these changes
Jan 17, 2025
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When creating a fsobj, e.g., a partition, we automatically modify associated fsobj-s (e.g., the underlying disk) to make them aware of the newly created object.
We do this through the use of backlinks and more specifically the function _set_backlinks. Currently, this function is automatically called first when entering the fsobj's
__post_init__method.If a fsobj defines its own
__post_init__method (let's called it user-defined), it gets called after_set_backlinks. This is usually fine.However if the user-defined
__post_init__raises an exception, we end up with backlinks referencing an object that was not successfully initialized.This is what happens with the Partition fsobj. In its user-defined
__post_init__, we determine the partition number by looking at the underlying disk. If the number could not be determined (because there is no more number available), we raise an exception "Exceeded number of available partitions". However, at this point, the underlying disk is already aware of the new partition - through the use of backlinks.Iterating over the list of partitions will then raise a TypeError when trying to use partition.number - which has not been successfully assigned.
Fixed by calling _set_backlinks after the user-defined
__post_init__, so that we only set the backlinks on success.LP:#2095159
This was causing double pain to people who were already affected by the installer suggesting buggy guided scenarios (e.g., LP:#2081724). If a user selects a buggy scenario, it would fail and leave the system in a bad state, making other scenarios more likely to fail too.