You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary: I would like the "command" key for the ansible provisioner to accept lists of strings.
Background: Internally, we have a wrapper around Ansible playbook which ensures that our Ansible playbooks run in the environment they expect. It is responsible for passing the right flags to ansible-playbook for common scenario's, checking preconditions, and some setup. (FWIW, I believe we're not unique in this: I've talked to quite a few people about the way they use Ansible setup and this is quite common from what I've heard)
The wrapper has a subcommand based CLI. So there is our-ansible-wrapper foo, our-ansible-wrapper bar, etc. Because of this, I would like Packer to call our-ansible-wrapper packer-provision PLAYBOOK. This is currently not possible without an intermediate shell script.
This is because those extra arguments are appended to the commandafter other arguments generated by Packer. So packer generates something like our-ansible-wrapper /path/to/playbook -i /tmp/inventory packer-provision.
More control over the order of arguments would be nice.
I currently work around this by having a separate shell script where the only purpose is to pass that additional argument to our wrapper. I'd prefer not to need it.
This request might generalize to other provisioners, but I haven't tried those yet.
The text was updated successfully, but these errors were encountered:
Sorry for the late response; this is a community-supported tool, which means the HashiCorp maintainers don't spend a ton of time on it. That said, it's probably a pretty straightforward task. All this requires is changing the string defined here into a []string, and following the Command call through the code to make sure that all of the calls to it handle its new format.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
ghost
locked as resolved and limited conversation to collaborators
May 17, 2021
This issue was closed.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is a feature request.
Summary: I would like the
"command"
key for theansible
provisioner to accept lists of strings.Background: Internally, we have a wrapper around Ansible playbook which ensures that our Ansible playbooks run in the environment they expect. It is responsible for passing the right flags to
ansible-playbook
for common scenario's, checking preconditions, and some setup. (FWIW, I believe we're not unique in this: I've talked to quite a few people about the way they use Ansible setup and this is quite common from what I've heard)The wrapper has a subcommand based CLI. So there is
our-ansible-wrapper foo
,our-ansible-wrapper bar
, etc. Because of this, I would like Packer to callour-ansible-wrapper packer-provision PLAYBOOK
. This is currently not possible without an intermediate shell script.What I've tried: This does not work:
This is because Packer tries to find a binary with a file name of the full
command
key. So including the space andpacker-provision
.Adding
packer-provision
toextra_arguments
also does not work.This is because those extra arguments are appended to the
command
after other arguments generated by Packer. So packer generates something likeour-ansible-wrapper /path/to/playbook -i /tmp/inventory packer-provision
.More control over the order of arguments would be nice.
Request: I would like this to work:
I currently work around this by having a separate shell script where the only purpose is to pass that additional argument to our wrapper. I'd prefer not to need it.
This request might generalize to other provisioners, but I haven't tried those yet.
The text was updated successfully, but these errors were encountered: