Expose connection settings in communicator to provisioners

[The-Loeki]

I'm trying to write a provisioner plugin for Salt SSH.
The process is largely similar to what Ansible does; open an SSH pipe and start doing stuff.

The problem I'm facing is therefore the same Ansible and a lot of other plugins seem to face: there's no access to the connection settings the Communicator already knows and the UI presents to me..
This leads to a lot of workarounds, from the Ansible Provisioner's 'SSH Proxy/Adaptor' to OpenStack's API calling to get that info again. it also leads to confusion (#3828) among users and and often the name has to show up multiple times in the JSON.

From what I can tell it's a matter of either adding a small method to provide that info or exposing the Config struct to the provisioners.

I propose to add such a function to the Communicator interface or expose Config.

Is that a good idea or am I missing a very good reason not to do it? Or is the situation much more complex than I'm anticipating now?

Related discussions:

• RFQ: Allow provisioner to get communicator details. #3331
• Allow remote ansible provisioner to bypass ssh proxying and simply connect based on sshHostPort state #3846
• Make ssh_host option available to provisioners #3404

[rickard-von-essen]

See #3331.

[rickard-von-essen]

#2991 is a bug and I think it has been fixed.

[rickard-von-essen]

I'm not sure what you mean by

OpenStack's API calling to get that info again.

And

The problem I'm facing is therefore the same Ansible and a lot of other plugins seem to face

Actually only ansible remote, and now you.

[The-Loeki]

ghehehe that hurt man ;) I thought I looked diligently, my apologies :)

Anyway, it seems the concerns focus around lack of use case (which I apparently read very wrong in the other plugins ;) ) and the availability of the SSH Proxy the Ansible provisioner already uses...

So my use case is Salt SSH, which, as mentioned is pretty similar to Ansible in setup. Given enough interest I'm planning to commit it here once it works.

In the meantime, is this sufficient to warrant further discussion or am I going to try to plug in the adaptor from the Ansible provisioner?

[rickard-von-essen]

I'm open for reviewing this design again. But this is a core design of Packer so changes must be done carefully with a well thought out design.

@cbednarski I guess these use cases will pop up from time to time. Maybe it's time to see if we can extend packer to allow such communication?

[chris-smith-zocdoc]

#3911 is impacted by this decision. If the connection settings were exposed, it should make adding support for Ansible + WinRM easier.

[kwilczynski]

@The-Loeki this is something that I was trying to convince people to do for some time.

Thank you so much for formalising what needs to be done in this issue.

[mwhooker]

This is a big question and not something we're ready to implement. We should revisit this after 1.0.