Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Destroy checkpoint after the module ran #194

Open
tyll opened this issue Apr 16, 2020 · 2 comments
Open

RFE: Destroy checkpoint after the module ran #194

tyll opened this issue Apr 16, 2020 · 2 comments
Labels
help wanted Possible issue for newcomers

Comments

@tyll
Copy link
Member

tyll commented Apr 16, 2020

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 #32 (comment)

@tyll tyll added the help wanted Possible issue for newcomers label Apr 16, 2020
@pcahyna
Copy link
Member

pcahyna commented Apr 17, 2020

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
Copy link
Member Author

tyll commented Apr 17, 2020

  1. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Possible issue for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants