ancorgs/space_policy.md

## space_policy.md

      
    Raw
  

              space_policy.md
            
          
    Initial remarks

When saying "drive" I mean any reused partitionable.
The spacePolicy is a concept that exists in the model but not in the config.
Right now, all drives in the model always have a spacePolicy value. Even those that do not
contain partitions, or that are going to be formatted, or whatever.
On the contrary, the UI only shows the SpacePolicyMenu when it makes sense. Since you only need
a policy when there is actually something to be decided by the user.
The current handling of spacePolicy

Conversion from model to config

# If the model does not indicate a space policy, then the space policy defined
# by the product is applied.
space_policy = model_json[:spacePolicy] || product_config.space_policy

# [... translate the policy to partition entries at the config ...]
Conversion from config to model

def convert
  return "delete" if config.filesystem || delete_all_partition?
  return "resize" if shrink_all_partition?
  return "custom" if delete_partition? || resize_partition?

  "keep"
end
Handling on the JS side

There is almost not handling of the policy expect setting its value to the value specified
by the user through the UI. Moreover,

When adding a new drive, spacePolicy is intentionally left blank
When set to "custom", some extra work is of course needed

Proposed handling number 1

The idea is to keep the impact low. On the long run, we may consider to go further and
use a policy only for those drives in which it makes sense.
Conversion from model to config

space_policy = "keep" if do_not_create_or_use_partitions?
space_policy ||= model_json[:spacePolicy] || product_config.space_policy

# [... translate the policy to partition entries at the config ...]
Conversion from config to model

def convert
  return "delete" if delete_all_partition?
  return "resize" if shrink_all_partition?
  return "custom" if delete_partition? || resize_partition?

  "keep"
end
Handling on the JS side

Almost the same, just adding one more point

When adding a new drive, spacePolicy is intentionally left blank
When adding the first partition for a disk was not used, reset policy to blank
When set to "custom", some extra work is of course needed

Problems of this approach

Implementing do_not_create_or_use_partitions? as part of the from_model conversion is not so easy.
Knowing that requires the whole picture (eg. whether the drive is chosen to boot, or is part of an LVM generate)
which is not available at that point.
Proposed handling number 2

Same idea than the previous proposal, but moving more responsibility to the JS part, since we
have more powerful methods there.
Conversion from model to config

Same than current
space_policy = model_json[:spacePolicy] || product_config.space_policy

# [... translate the policy to partition entries at the config ...]
Conversion from config to model

Same than current but removing the "delete" introduced on if config.filesystem
def convert
  return "delete" if delete_all_partition?
  return "resize" if shrink_all_partition?
  return "custom" if delete_partition? || resize_partition?

  "keep"
end
Handling on the JS side

JS takes care of the following cases:

When adding a new drive, spacePolicy is set to "keep"
When formatting a disk, spacePolicy is set to "keep"
When deleting a partition from a disk, if that leads to !isUsed then set policy to "keep"
When adding the first partition for a disk that !isUsed and has policy "keep" , reset policy to blank
When setting lvmTarget for a disk that !isUsed and has policy "keep", reset policy to blank

Cases in which we don't need to handle spacePolicy because the drive will be deleted from the configuration:

When removing a disk from explicitBoot if that leads to !isUsed.
When removing disk from the list of targets of a VG if that leads to !isUsed.
When removing a VG that had the disk as target if that leads to !isUsed.
When setting explicitBoot for a disk that !isUsed and has policy "keep". No need to set it to blank because actually setting it to "keep" (instead of resetting it to the default) is the right thing to do when the disk is used only to boot from it.

Problems of this approach

Obviously, many more cases to control at the UI.
No results found