Reevalute storage reprobing strategy

[joseivanlopez]

The storage system is now reprobed if something changes in the system (e.g., iSCSI sessions are created). With the current approach, the storage D-Bus service sets the system as deprecated, and clients react to this. So, the clients are responsible of triggering a repobing when the system becomes deprecated.

Theoretically, clients would not have to take care of reprobing at all. The storage service knows when a reprobing is needed. For example, if an iSCSI session is craeated or deleted, then the service could trigger a complete reprobing (libstorage-ng probe, iSCSI probe, etc), and then it recalculates the current proposal. With the current approach, only the iSCSI probe is done and the system is marked as deprecated.

• Current approach (deprecating system):
  • Pros:
    • The system is only reprobed once after serveral changes in the system (e.g., iSCSI session created, closed, etc).
    • Questions are raised only when the client requests a reprobing.
  • Cons:
    • A deprecated state if needed.
    • Clients take care of reacting if the system is deprecated.
    • A partial probe like iSCSI probe is done and then iSCSI is probed again as part of the general reprobing.
• Automatic service reprobing:
  • Pros:
    • No need of a deprecated state (the system is never deprecated).
    • The clients only takes care of proposal changes, as usual.
    • There is no risk of being working with an outdated system representation.
  • Cons:
    • Too many probe/proposal calls (which could be expensive).
    • Questions could be raised after each change in the system.

[kobliha]

Also please consider the unattended installation / commandline. Who should trigger the reprobing and when?

IMHO, we've would benefit from a partial reprobing in libstorage, i.e., storage is reprobed automatically in case when the list of devices changes (or when D-Installer calls it dirty?) and then libstorage keeps details about already probed devices, but probes all details about the new ones. What I'm asking is kind of a cache in libstorage.

Let's imagine this: system is probed with sda and sdb. Now user plugs something in and get additionally sdc and sdd. In this case, sda and sdb are considered unchanged and sdc and sdd will be probed for details. I know this is very simplistic view, but let's try to think about it :D The other case is simpler two from fours disks are removed. Then everything that depends on them would be also removed, e.g., LVM, RAID, etc. or reprobed, depends.

Of course, it may happen, that the user changes something on the disk manually using a commandline in the terminal. Then the user is responsible for going to the menu and calling full reprobing that would invalidate the cache. Or even a reprobing cmdline.

In other words: automatic reprobing can be just a partial (light) one - only for new devices (or removed ones). Full (heavy) reprobing would be only on request.