include manually-created snapshots #69

Activity

1. ahrens commented on Jun 9, 2018

   

   ahrens

   on Jun 9, 2018

   Author

   More actions

   Another complication here is if you rename the manually-created snapshot.
2. problame

   added

   feature

   on Jun 18, 2018
3. problame commented on Jun 18, 2018

   

   problame

   on Jun 18, 2018

   Member

   More actions

   Another complication here is if you rename the manually-created snapshot.
   Snapshots should be identifiable across renames by the guid attribute.

   With regards to the main feature request: I think the main use case would be something like:
   An administrator wants to snapshot the system right before the upgrade, make sure it is replicated off-site, then do the upgrade, and get rid of the snapshot a few hours afterwards.

   The way snapshots are selected for replication right now is a simple prefix test with the snapshot_prefix attribute.
   On the source, it is a filter for what the client can see via RPCs and it is used for pruning.
   On the pull side, it is also used for filtering snapshot names in the RPC response, and for pruning.

   The reasoning behind the filtering is that I wanted to enable zrepl to coexist with other automatic snapshotters on the source side (hence prefix and filtering) (A).
   For the pull side, the prefix is merely a safety net, in the sense that the admin can manually snapshot the expensively replicated file system with a non-matching prefix and be assured that the zrepl daemon won't even consider it for pruning (B).

   I think that both design decisions A and B were made without much foresight, in particular with regards to this feature.
   Hence, we should revise them and see if there is something better before we try to build the feature requested in this PR (we need a short name for it!).

   Alternative to prefix filtering

   • As @ahrens taught me at BSDCan, we can actually have properties on filesystems
   • The snapshotter could set a snapshot property zrepl:replicate=on.
   • The same property could be set on a manually created snapshots
     • e.g.: zrepl snapshot foo@a = zfs snapshot foo@a && zfs set zrepl:replicate=on foo@a
   • source would present all snapshots with zrepl:replicate=on via RPC
   • pull would pull everything presented by source
     • the existing replication algorithm uses the guid property, should be fine
   • destroying snapshots on source converts snapshot into a bookmark to allow remote side to continue incremental replication with next automatic snapshot
     • zrepl destroy foo@a = zfs bookmark foo@a foo#a && zfs destroy foo@a

   Benefits

   • zrepl replicate JOBNAME command possible, would be idempotent
   • zrepl replicate --dosnap JOBNAME would combine the new zrepl snapshot and zrepl destroy commands

   Drawbacks

   • zfs set is yet another syncing action in autosnap task
     • solvable, see related issues snapper: parallell snapshotting, preferrably using channel programs #62 ZFS channel program support #46 (parallel task, channel programs)
   • need conversion path to set zrepl:replicate property to snapshots with the prefix (from the config)
     • we still have the prefix in the config, and still need it for autosnapshots
     • but the prefix will have different meaning, need to document that...

   Comments? Am i overcomplicating things?

   👍React with 👍1Reacted by MoritzFago
4. problame

   added this to the 0.0.5 milestone on Jun 18, 2018
5. problame

   added

   analysisA proposal / feature request that needs more analysis / be converted into actionable items.A proposal / feature request that needs more analysis / be converted into actionable items.

   on Jun 18, 2018
6. ahrens commented on Jun 18, 2018

   

   ahrens

   on Jun 18, 2018

   Last edited by ahrens

   Author

   More actions

   There's a small cost to having properties on snapshots, so it might be worth having the selection algorithm be "named zrepl_* OR has zrepl property". This way the majority of the snapshots (the auto-created ones) would not need properties. This also solves the "conversion path" issue.
7. problame commented on Jun 18, 2018

   

   problame

   on Jun 18, 2018

   Member

   More actions

   What causes the cost? Is it caused by the first user-created property because the hash map (ZAP, right?) is initialized only then?
8. ahrens commented on Jun 19, 2018

   

   ahrens

   on Jun 19, 2018

   Author

   More actions

   Yes, the ZAP object of snapshot properties usually doesn't exist, but is instantiated when the first user property is added.
9. problame commented on Jun 20, 2018

   

   problame

   on Jun 20, 2018

   Member

   More actions

   It is still unclear how and when the snapshot on both sides is deleted, in particular on the pull side.

   Given the admin-usecase outline above, I think that manual snapshots should not be covered by the regular pruning policies on either side.

   • Alternative 1: manual deletion by admin on receiving side

     • The admin may want their well-defined pre-upgrade system state to be untouched until they know the update worked
     • Simple to understand

   • Alternative 2: encode receiving-side pruning policy as snapshot property

     • Have a zrepl:prune snapshot property, like zrepl:prune=<prune_policy_sender>|<prune_policy_receiver>
     • values for prune_policy_sender and prune_policy_receiver could be:
       • manual - Admin will destroy snapshots manually, as in alternative 1
       • after=<utc_date> - Destroy at UTC date (UTC because the two replication sites may have different time zone)
       • count=<n>, keep n of the snapshots that are not covered by the regular prune policy
       • Go crazy: essentially, any supported pruning policy that can be put into a oneline-form could be supported.
         • from an implementation standpoint, the zrepl daemon could scan the list of snapshots, construct a prune policy object in addition to the regular prune policy object, and just apply both sequentially
     • The RPC protocol would need to be extended to communicate the property
       • Could be covered by Property Replication ( Property Replication #24 ): the receiving side knows that it is a receiver and can thus follow the prune_policy_receiver.
     • Pro: flexible, may be useful for manually triggered ad-hoc replication (e.g. backup my laptop NOW in addition to the regular time interval)
     • Con: another domain specific language

   Alterantive 1 won't add to the RPC protocol, only to the filter code on sending and receiving side.
   Alternative 1 is essentially the manual policy in alternative 2.
   An implementation could start with alternative 1 and when switching to alternative 2, default to manual policy if a legacy snapshot doesn't have the zrepl:prune property.

   Is alternative 2 overkill? Any other ideas?
10. problame

    added

    in_changelog_0.1

    on Sep 27, 2018
11. problame

    closed this as completedon Oct 17, 2018