• Can we split ZAM into two users? One for creating snapshots, one for deleting them? Does that improve security at all? If not, we should at least have one for local and one for remote.
• We should make it easy to give the ZAM user(s) the right permissions. We could do sudo zam --set-zfs-permissions, but I don't like giving ZAM root, even if only briefly. We could instead do ~zam --get-permission-commands, with the expectation that the user manually runs each command with an understanding of what it does.

I tentatively want this implemented before adding ZAM to the AUR. If my opinion changes, the priority will be reduced.

Thus far when creating ZAM, I've basically skipped the design phase. This was a mistake.

We need, for example:

• abstraction layers (protocols)
• a (UML?) document describing the relation between the different classes/protocols
• ...

We need an installer so that future updates can be easily installed

Until the new config design is finalized, we should not waste time maintaining the current config code. As such, it should be deleted and instead we should just hard code values for testing.

The run function in the task protocol of scheduler.py is responsible for both running the class and computing the time at which it should next be run. These responsibilities should be split into separate getNextActionionableDatetime (?) and run functions.

Besides just making for a cleaner interface, this would also allow the scheduler to fully initialize its prioritized heap without having to actually run each task.

Currently ZAM config must specify each individual dataset. We should add a way to recurse on a dataset or zpool.

Recursive entries should have an optional blocklist (prefix match string literal, or regexp?).

When operating on a dataset, we should use the best fit from the config. e.g. if the config defines the foo and foo/bar datasets, then foo/bar/baz should use the settings from foo/bar. Equivalently (?), a config entry for foo/bar/baz defines an implicit blocklist entry on foo/bar (which in turn is blocked from foo).

Currently all three actions loop with a period of ~min({snapshot,replication,prune}-period). They should be on separate timers.

Co-routines would be a good fit for this problem?

Nobody reads logs. How is the user expected to notice if ZAM repeatedly fails to update a replica? ZAM should somehow notify the user if it hasn't updated a replica for N days. Similarly, we should notify the user any time that ZAM itself crashes.

My current preference for the method of notification is a /etc/profile.d/*.sh script that basically cats some sort of ZAM log file. The user could clear the messages by either deleting the log file, or updating some sort of $HOME/.local/share/zam/ignore_message_before_this_date file.

We need to simplify the process of setting up ZAM on a machine for the first time. In addition to the items described by #1, this may include:

• Creating a daemon user for local use (i.e. actually for actually executing the ZAM script)
• Creating a daemon user for remote instances of ZAM to use
• Ensuring that the daemon users have sufficient ZFS permissions
• Setting up SSH keys to access the remote replicas
• Getting ZAM in the AUR

Currently the task scheduler requires that the task be able to deduce exactly when it will next need to run. How should we handle cases where it doesn't know when to run next? For example, a replicator_task might want to only run when the device is not in use. Currently it can schedule itself for midnight, but it has no recourse if the device is still in use when midnight arrives besides duplicating scheduling logic in the runner function.

In order to cleanly support this sort of use case the task.get_next_runtime function should be refactored to task.get_next_possible_runtime. Before the task is run, this function should be called again to see if the time has moved back.

Find a better way to model stand-alone functions; the markup (and rendered image for that matter) look horrible:

	class "<<public members>>" {
		run(tasks: typing.List[task]) -> None
	}

It's a pain to have to maintain from_dict functions.

With the current config framework you might, for example, have to specify the exact same destination replica multiple times for many managed datasets. There should be some syntax for avoiding this. e.g. enable setting a default value from a broader context:

{
    "DEFAULT#managed-datasets[*].destinations": [
        {
            "remote-host": "olympus",
            "pool": "o-nas",
            "dataset": "zam/s-root/data/home/i",
            "windows": [
                {"max-age": {"weeks": 6}, "period": {"hours": 1}},
                {"max-age": {"months": 6}, "period": {"days": 1}},
                {"max-age": {"years": 6}, "period": {"weeks": 1}},
                {"period": {"months": 1}}
            ]
        }
    ],
    "managed-datasets": [
        {
            "source": {
                "pool": "s-root",
                "dataset": "data/home/i",
                "windows": [
                    {"max-age": {"days": 2}, "period": {"minutes": 10}},
                    {"max-age": {"weeks": 1}, "period": {"hours": 1}}
                ]
            },
            "snapshot-period": {"minutes": "10"},
            "replication-period": {"hours": "1"},
            "prune-period": {"hours": "1"}
        },
        {
            "source": {
                "pool": "s-root",
                "dataset": "root/default",
                "windows": [
                    {"max-age": {"weeks": 1}, "period": {"hours": 3}}
                ]
            },
            "snapshot-period": {"minutes": "10"},
            "replication-period": {"hours": "1"},
            "prune-period": {"hours": "1"}
        }
    ]
}

Or better yet, use some sort of super-fancy variables:

{
    "DEFINE#dest-default-dataset": "zam",
    "DEFINE#dest-default": {
        "remote-host": "olympus",
        "pool": "o-nas",
        "windows": [
            {"max-age": {"weeks": 6}, "period": {"hours": 1}},
            {"max-age": {"months": 6}, "period": {"days": 1}},
            {"max-age": {"years": 6}, "period": {"weeks": 1}},
            {"period": {"months": 1}}
        ]
    },
    "managed-datasets": [
        {
            "source": {
                "pool": "s-root",
                "dataset": "data/home/i",
                "windows": [
                    {"max-age": {"days": 2}, "period": {"minutes": 10}},
                    {"max-age": {"weeks": 1}, "period": {"hours": 1}}
                ]
            },
            "destinations": [
                {
		    "REF": "dest-default",
                    "dataset": "${dest-default-dataset}/s-root/data/home/i",
                }
            ],
            "snapshot-period": {"minutes": "10"},
            "replication-period": {"hours": "1"},
            "prune-period": {"hours": "1"}
        },
        {
            "source": {
                "pool": "s-root",
                "dataset": "root/default",
                "windows": [
                    {"max-age": {"weeks": 1}, "period": {"hours": 3}}
                ]
            },
            "destinations": [
                {
		    "REF": "dest-default",
                    "dataset": "${dest-default-dataset}/s-root/root/default",
                }
            ],
            "snapshot-period": {"minutes": "10"},
            "replication-period": {"hours": "1"},
            "prune-period": {"hours": "1"}
        }
    ]
}

Bear in mind that one of the primary objectives of this project is to use as few lines of code as possible. Is this feature worth the extra LOC?