RFE: Destroy checkpoint after the module ran

[tyll]

Change the checkpoint code to:

1. Not to commit/destroy the checkpoint directly in the module when the transaction is complete but instead to return the dbus path of the checkpoint (for example /org/freedesktop/NetworkManager/Checkpoint/66)
2. Decrease the remaining checkpoint lifetime before exiting the module to a short time that is considered enough for the next step
3. Add another step in the role tasks file after the current call of the module to destroy the checkpoint. Maybe it can just be a command like

gdbus call --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager --method org.freedesktop.NetworkManager.CheckpointDestroy /org/freedesktop/NetworkManager/Checkpoint/66

when the network_provider is nm.

Copied and adjusted this from https://github.com/linux-system-roles/network/issues/32#issuecomment-614800266

[pcahyna]

3. Add another step in the role tasks file after the current call of the module to destroy the checkpoint.

Just an idea, would it make sense to do it in a handler?

Handlers are executed at the end of the playbook, after the role (and other tasks) has completed. This would expose the checkpoint functionality to the users and allow them to make their playbooks transactional (not just the role call). I am sure it would have disadvantages as well, the whole thing would become less transparent and more error prone, so consider it just brainstorming.

@greg-hellings @robled what do you think? https://github.com/oasis-roles/meta_standards/blob/master/README.md#ansible-best-practices says "Avoid the use of when: foo_result is changed whenever possible. Use handlers, and, if necessary, handler chains to achieve this same result." And the suggestion seems to conform to this logic.

[tyll]

3. Add another step in the role tasks file after the current call of the module to destroy the checkpoint.

Just an idea, would it make sense to do it in a handler?

Handlers are executed at the end of the playbook, after the role (and other tasks) has completed. This would expose the checkpoint functionality to the users and allow them to make their playbooks transactional (not just the role call). I am sure it would have disadvantages as well, the whole thing would become less transparent and more error prone, so consider it just brainstorming.

One problem I see would be the timeout for the checkpoint. It would be good to keep it as short as possible to revert back on failures ASAP but when using a handler in a complex playbook it might take some time till the handler is called.