Add fsFreeze field to VolumeSnapshot

[ejweber]

Which issue(s) this PR fixes:

longhorn/longhorn#2187

What this PR does / why we need it:

• Proxy the freezeFS field for SnapshotVolume through to the engine.
• Attempt to unfreeze all file systems on the root partitions of Longhorn volumes on startup.

Additional documentation or context

Depends on:

• Add freezeFS field to VolumeSnapshotRequest types#8
• Add fsfreeze functionality to snapshot longhorn-engine#1083

Need to fix imports before merging.

[mergify]

This pull request is now in conflict. Could you fix it @ejweber? 🙏

[mergify]

This pull request is now in conflict. Could you fix it @ejweber? 🙏

[PhanLe1010]

• Proxy the freezeFS field for SnapshotVolume through to the engine.
• Attempt to unfreeze all file systems on the root partitions of Longhorn volumes on startup.

Is it correct that we are not going to periodically check and unfreeze the filesystem of a crashed engine like:

• instance-manager pod is still running
• engine crashed
• engine move to new node
• instance-manager of old node is not going to unfreeze the filesystem on old node

[ejweber]

Is it correct that we are not going to periodically check and unfreeze the filesystem of a crashed engine like:

It is correct (unless there is pushback of course). This is my opinion on why:

• The engine doesn't actually usually "crash". Usually it transitions to an error state because (for example) it lost all connections with a replica. Then, it is shut down. We do implement shutdown logic that will ensure it is unfrozen in this case.
• If the engine literally does go away with any shut down logic (e.g. with a kill -9), it is usually automatically reattached by Longhorn. We do implement logic that will ensure it is unfrozen on startup.

In my opinion, the complexity of periodically scanning for and attempting to unfreeze file systems for engines that happen to somehow crash without going through any shutdown at the exact moment they are frozen introduces more risk than the potential for this situation to leave the file system frozen does. (Especially in the case where we have multiple instance managers running simultaneously, as still often happens for v1.)

Keep in mind that if it does happen, it is not nearly as serious as the other cases we investigated. With a look at the support bundle, we can determine the file system was frozen, but never unfrozen, and suggest an unfreeze command.

[PhanLe1010]

Agree! Multiple instance-manager case introduces significant complications if we introduce the periodically check and unfreeze in IM

[mergify]

This pull request is now in conflict. Could you fix it @ejweber? 🙏

[james-munson]

LGTM.

[ejweber]

I rebased this one and it is now ready (pending a successful CI build, of course). Please check it again when you have a moment @PhanLe1010 and @james-munson.

[james-munson]

No issues.

[PhanLe1010]

LGTM

[mergify]

This pull request is now in conflict. Could you fix it @ejweber? 🙏

[ejweber]

Hello @PhanLe1010, @shuo-wu, and @james-munson. I have resolved the conflict. Can I have an approve again from one of you so I can merge? Thanks!