Hello Ansible Community,
Last week I opened a PR on the main Anisble repo implementing a feature that was requested in an issue nearly 10 years ago. I also had reason to use this feature so I thought it’d be worth spending some time to knock it out. Unfortunately, the issue was closed with the only explanation being:
We recommend writing a custom plugin for this particular case as we think this would complicate the UI.
Unfortunately, this does not clarify who the “we” in question is or who I should I talk to about what changes they would like to see. Especially given this is only adding 2 optional parameters, I find it strange that this would be “too complicated”. Additionally, with the PR being closed, the commenter states that they will be unlikely to see any further discussion on that thread so it seems like the forum is the next best place for communications? Has anyone else ran into this before? Is there some sort of discussion on this topic where I could get more information?
To clarify: ‘we’ is the ‘ansible project core team’, the ones that maintain ansible.
This team meets to discuss issues (currently x2 a week) and as a result of this discussion we realized that the old issue is not something we think fits into the core package anymore and that a custom/dedicated plugin is more appropriate for what seems to be a niche case than adding this to the existing pause action that aims to maintain a minimal set with wide applicability.
This post you opened is the correct way to have ‘further discussions’ on the topic if you feel that our assessment was incorrect and allows people from the broader community to add their inputs in hopes of making us rethink our conclusions.
Out of curiosity, why does it not fit within the plugin anymore? I’m guessing the thought is that pause is really meant just to pause so adding too many prompting features around it is a departure from the usage expected by the name?
I was also looking at the prompt interactive input (which would probably be the more appropriate location), however, if I’m understanding it correctly, that only runs at the start of a play, making it tough to create dynamic prompts.
The new options clash with the existing time options (timeout_* vs mintues/seconds).
Also the timeout_action seems to try to incorporate too much into the action, normally a handler or a 2nd task with a conditional could cover this already.
All this adds more complexity to pause for very little payback, since moving to collections we try to minimize adding to core actions unless there is a very compelling reason. Since it is very simple to create and use plugins in collections we favor that for most new functionality, specially if we see it as something niche.
I mean, the timeout could be combined with minutes/seconds but given minutes/seconds kills prompt (which seems unintuitive to me at least), it wouldn’t provide any value as far as I can tell. I’m assuming there’s some sort of rationale from prompt not working with minutes/seconds that I’m missing out on. But I’d at least be willing to investigate what would be required to make prompt work with minutes/seconds.
Re timeout_action, initially I assumed a timeout without input would just exit but I can see it being useful to allow continuation. Anyways, that could definitely be pulled out.
I like the approach suggested by bcoca more than the one that was implemented, but I’d use two tasks if I needed to accomplish this, so I just don’t see much benefit. Have you considered using an initial pause task with seconds/minutes, and conditionals to fail/prompt the user/proceed without interaction based on the result?
Things have changed a lot since the request was made over 10 years ago in 2015. There was no good way to share custom plugins, and handling prompting in connection/action plugins relied on internal implementation details. Since 2.9, many plugins in ansible/ansible were moved to collections and ansible/ansible is more selective about new features. Since 2.15, ansible.utils.display provides a stable way for action plugins to prompt until an optional timeout, so this should be easy to add to a custom plugin now.