Document the approach for resizing and deleting devices

[ancorgs]

Created as a pull request on top of agama-project#1455.

This describes the way to approach to resizing in the auto-format of Agama.

[ancorgs]

Let's elaborate a bit in the most technical part how all this could be achieved.

Let's start with a small reminder on how resizing works in the current SpaceMaker.

class Proposal::PartitionsDistributionCalculator
  # [...]
  # Space that should be freed when resizing an existing partition in order to have a good chance
  # of creating a valid PartitionsDistribution (by means of #best_distribution).
  #
  # It does not take the limitations of the partition into account (eg. whether it can be
  # resized or how full it is)
  def resizing_size
    # This tries to create valid distributions
    # If resizing does not result in any valid distribution, returns current size
  end
end

class Y2Storage::Proposal::SpaceMakerActions::Shrink
  # @return [DiskSize] size of the space to substract ideally
  attr_accessor :shrink_size

  # Reduces the size of the target partition
  #
  # If possible, it reduces the size of the partition by {#shrink_size}.
  # Otherwise, it reduces the size as much as possible.
  # 
  # This method does not take alignment into account.
  def shrink(devicegraph)
     [...]
  end
end

Taking that into account, the following steps/changes could be inserted in the general AgamaProposal algorithm to handle all the reasonable situations.

First of all, Beware the usage of "current" can lead to strange situations like:

• Real size: 10 GiB. Min: "current". Max: 5 GiB

Those cases should be watched. The steps below assume that does not happen.

Step 1. When calculating the SpaceMaker actions, generate one shrink for every partition in which min is smaller than the current size.

How to determine the size of the shrink action?

suggested = current - calculator.resizing_size
target_size =
if min > suggested
    min
elsif max < suggested
    max
else
    suggested
end

The action is mandatory if the max is smaller than the current size. Otherwise is optional.

Step 2. To be done on every attempt. That is:

• Before starting with the optional actions and also after every action
• Before calculating the corresponding distribution
• For all partitions that need to grow (that can be optimized, not all partitions are affected by each action)

def needs_to_grow?(partition)
  partition.min > device_at_working_devicegraph(partition.found_device).size
end

if needs_to_grow?(partition)
  immediately_try_to_grow_up_to_min(partition)
  # Maybe it would be useful to remember the result
  #
  # It can fail because there is still not enough space, then that distribution is not valid
  # and we need to keep trying stuff.
  #
  # It can fail because there was space but something else at resize_info prevents
  # the partition from growing.
  # Should we abort? I guess so, that's what "min" means after all.
end

Step 3. When distributing extra space at the end of the algorithm

Take into account partitions that could_grow and are right before the space

def could_grow?(partition)
  partition.max > partition.current && partition.resize_info.max_size > partition.current
end

A general notes regarding the order in which we decide what to delete: maybe we should prioritize to delete partitions that are after a partition that needs to grow. If I remember correctly, the only criteria is starting by the end of the disk, but it could be way smarter.

[joseivanlopez]

I like the idea. The only specific actions are about deleting. The rest is inferred from the declarative properties (e.g., filesystem, size, etc).

In fact, there could be different schemas:

Partition
  Search
  Delete

Partition
  Search
  Size
  DeleteIfNeeded

Partition
  Search
  Size
  Filesystem

That would avoid having incompatible configs like indicating Delete and DeleteIfNeeded at the same time.