rock-ons-root snapshot warning

[phillxnet]

Thanks to knucklehead101, mrseth1, glenngould, MvL, and D_Jones in the following forum threads for highlighting this issue. Since docker (Rockons) use snapshots to manage image layers their deletion will break installed Rock-ons. Provide a banner / warning against this action in the current Rock-ons-root share (sub-volume).

It is proposed (by the issue author) that this banner / warning / explanation be placed inside the "Snapshots" tab on the currently active rock-ons-root share (sub-vol).

Referenced forum threads:
https://forum.rockstor.com/t/rock-ons-snapshot-removal/637
https://forum.rockstor.com/t/deleting-snapshots-breaks-rock-ons/2431
https://forum.rockstor.com/t/what-is-the-logic-of-rockstor-if-there-are-no-scheduled-snapshots/2928
https://forum.rockstor.com/t/solved-headphones-rock-on/3034
https://forum.rockstor.com/t/broken-rockons-after-update-or-snapshot-removal/3039

Possible background docker reference:
https://docs.docker.com/engine/userguide/storagedriver/btrfs-driver/

Note additional 'auto clean' functions can later be added to this share (sub-volume) using the recently introduced ' docker system prune' and friends but that is for another / later issue. This issue is about user communication re docker snapshot use and visibility within the UI.

We have an open partner issue in our rockstor-doc repo:
explain rock-ons-root snapshots
rockstor/rockstor-doc#166

[MFlyer]

Adding my 2 cents:
while testing share usage/rusage issues noticed every Rock-on / docker snapshot generates same warning when deleting shares.
My suggestion : find a way to identify docker like snapshots, lock them and make them not blocking when dealing with shares deletion

@phillxnet @schakrava ?

[phillxnet]

Please also update the following forum thread with this issues resolution:
https://forum.rockstor.com/t/snapshot-removal-issue/4795

[FroggyFlox]

While thinking about that one, I keep coming to the following thought: "Shouldn't we "simply" disable or prevent snapshots on the rockons_root share?"

Is there an actual benefit to snapshotting this share? If my understanding is correct, the only data placed on this share is:

• docker containers layers from images: can simply be re-created upon re-installing the corresponding rock-on
• docker "init" files (from its daemon?): this should easily be re-created by turning off and on the Rock-on service.

If the above is correct, one can easily identify the rockons_root share as it is stored in SmartManager Service table and use this to exclude it from snapshots (not sure how that one works, unfortunately), or as a quick workaround hide all snapshots of this share from the list of snapshots on the webUI.

Any thought?

[phillxnet]

@FroggyFlox I think the issue here is that docker itself uses snapshots for the layers I think and we simply surface them, which is correct, when one views the rock-ons-root.

Don't like the hiding idea, but maybe labelling the docker related snapshots and warning that that is what they are.

See my docker reference above, reproduced for convenience:
"Possible background docker reference:
https://docs.docker.com/engine/userguide/storagedriver/btrfs-driver/
"
Which shows the specifics of the docker bttfs driver re subvols / snapshots.

So it's not us or the users taking snapshots, it's how docker works with btrfs when using the btrfs-driver. It gains efficiency that way. We just need to 'handle it' and communicate this element to the users who have often 'cleaned up' all these snapshots and broken all their dockers/Rock-ons.

[phillxnet]

Pertinent quote from: https://docs.docker.com/storage/storagedriver/btrfs-driver/

"Only the base layer of an image is stored as a true subvolume. All the other layers are stored as snapshots, which only contain the differences introduced in that layer. You can create snapshots of snapshots as shown in the diagram below."

Quite clever really.

[FroggyFlox]

I realize I explained myself very poorly in my previous post, @phillxnet, I apologize for the waste of time and energy.

Instead of referring to snapshots, I should have referred to Rockstor's UI for snapshots. So for instance, we could add a @property method to the Snapshot storageadmin class model named isDocker that is set to true if share == rockons_root (fetched from the Service SmartManager table). We could thus use this to disable the "delete" action for a given snapshot if isDocker: true, with a help message when hover explaining that this action has been disabled because this snapshot corresponds to a container layer.

The logic above is similar to what we have to prevent a user from deleting the network connection currently used to access the webUI.

There are quite a bit of places in the webUI where snapshots are displayed, though, but that could be doable... or am I still missing the obvious here? I'm deeply sorry if that's the case...

This logic would not be robust to user-created snapshots of the rockons_root share, but would we loose something by preventing a user from making a snapshot of the rockons_root share?