I suppose I could do both. I personally prefer the explicit vars- I find it
makes the playbooks more readable and maintainable than deciphering
ssh_args line noise. I can see where it'd nice to have the "escape hatch"
to do unsupported things, though, too. The trick is getting everything to
behave if things get set with the explicit vars and also in ssh_args-
there's a bit of code in ssh.py to deal with that already (ssh_args takes
precedence IIRC), but there would probably need to be a lot more to make it
really robust.
On Wednesday, October 29, 2014 10:26:26 AM UTC-7, erewh0n wrote:
>
> If there was a more generic "ansible_ssh_args" parameter, it could be used
> however the user sees fit. It's a more flexible approach because it
> assumes less about how the parameter might be used or implemented in SSH.
> It just means a little more overhead for the user to know how to construct
> that string correctly.
>
>
> On Wednesday, October 29, 2014 1:04:45 PM UTC-4, Michael Peters wrote:
>>
>> I think that would be my preference. I know in the past there's been
>> some pushback against implementing more ansible_ssh_* parameters
>> because that's long rabbit whole considering the number of ssh
>> configuration parameters that exist. I agree with this point, so if
>> adding one more (ansible_ssh_proxy) is too much, then maybe a last and
>> final ansible_ssh_config to point to a config file on a
>> per-host/play/task level. Then anything you want can be put into that
>> config file and ansible itself wouldn't have to ever add any other
>> ansible_ssh_* parameters.
>>
>> Either way would solve the problem, although the latter is more
>> complicated to implement for users (would probably need to have the
>> dynamic inventory dynamically generate ssh config files too).
>>
>> On Wed, Oct 29, 2014 at 12:45 PM, Tennis Smith <ten...@nextgxdx.com>
>> wrote:
>> >
>> > How about implementing "ansible_ssh_proxy" to match "ansible_ssh_user"
>> and
>> > "ansible_ssh_host"?
>> > -T
>> >
>> >
>> > On Wednesday, October 29, 2014 11:36:42 AM UTC-5, erewh0n wrote:
>> >>
>> >> Good point -- so configuration per play might be inflexible. I guess
>> the
>> >> better choice is a variable that can be modified per host/group/play.
>> Call
>> >> it "ssh_args" and give it the same meaning as ANSIBLE_SSH_ARGS.
>> Assign it
>> >> per host, group or play where required and use the "-o" option to pass
>> in
>> >> ProxyCommand parameters.
>> >>
>> >> This seems pretty clean, although I'm not sure what the convention is
>> for
>> >> exposing new "global" variable state in Ansible. :)
>> >>
>> >>
>> >> On Wednesday, October 29, 2014 12:19:41 PM UTC-4, Michael Peters
>> wrote:
>> >>>
>> >>> Another use case to consider (that I myself have come up against) is
>> >>> configuring the bastion per-host from a dynamic inventory. The
>> servers
>> >>> need to use a different bastion depending on their role and location.
>> >>>
>> >>> On Wed, Oct 29, 2014 at 12:17 PM, erewh0n <keith....@gmail.com>
>> wrote:
>> >>> > Thinking on this a bit more ... it seems there are two use cases
>> here:
>> >>> > how
>> >>> > to dynamically change your SSH control connection during playbook
>> >>> > execution
>> >>> > and how to subsequently refer to the new bastion host on subsequent
>> >>> > calls to
>> >>> > ansible-playbook. If you could set SSH arguments per play, then I
>> >>> > think
>> >>> > both of these cases are addressed:
>> >>> >
>> >>> > - hosts: all
>> >>> > connection: ssh
>> >>> > connection_args:
>> >>> > proxy_host: {{ groups.bastion[0] }}
>> >>> > proxy_port: 22
>> >>> > user: johndoe
>> >>> >
>> >>> > The 'connection_args' feature implies you no longer require SSH
>> config
>> >>> > files
>> >>> > (but could optionally use them if preferred). It could be used
>> >>> > dynamically
>> >>> > within a playbook to override your defaults that come from
>> >>> > "ANSIBLE_SSH_ARGS", for example.
>> >>> >
>> >>> > I can see an argument for just specifying raw SSH command line
>> >>> > arguments as
>> >>> > well, something like:
>> >>> >
>> >>> > - hosts: all
>> >>> > connection: ssh
>> >>> > connection_args:
>> >>> > command_line: "-o ProxyCommand ssh -W %h:%p -l johndoe
>> johndoe@{{
>> >>> > groups.bastion[0] }}"
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "Ansible Project" group.
>> >>> > To unsubscribe from this group and stop receiving emails from it,
>> send
>> >>> > an
>> >>> > email to ansible-proje...@googlegroups.com.
>> >>> > To post to this group, send email to ansible...@googlegroups.com.
>> >>> > To view this discussion on the web visit
>> >>> >
>> >>> >
>> https://groups.google.com/d/msgid/ansible-project/2f75fa3d-cc99-4bc5-aa3b-28562d9d8db9%40googlegroups.com.
>>
>>
>> >>> > For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Ansible Project" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to ansible-proje...@googlegroups.com.
>> > To post to this group, send email to ansible...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/ansible-project/df0108fb-0405-4f10-8b04-2295a3912b7a%40googlegroups.com.
>>
>>
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/fc7d5537-0eb9-445f-82ac-2ea22f81687a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
