The ssh_user and ssh_port parameters

The ssh_user and ssh_port parameters are complex and undocumented.

Old (released) system. The template create.yml hard coded ssh_user and ssh_port to ubuntu and 22. This was passed in to the instance config. driver.py read these from the instance config and used them to set the ansible_user and ansible_port portions of the connection options. To override them required setting ansible_user and ansible_port in the connection_options portion of the platform definition.

New system. The template create.yml reads ssh_user and ssh_port from the platform, the defaults are ubuntu and 22. This is used during the creation process, the user is set via cloud-init unless the key_inject_method is overridden and the port is used when polling until the instance starts. These are then passed via the instance config to driver.py and used to populate ansible_user and ansible_port for downstream inventory use.

I detailed both to highlight the backwards compatibility issue. My prior practice was to specify the ansible_user in connection_options, for example setting it to admin for a Debian distribution. This configured the inventory for the subsequent ansible stages, commands such as `molecule login` also worked. Using current master that breaks badly, cloud-init is used during create to set the user to ubuntu. The inventory is then configured to use admin, which breaks everything. The cause is not obvious.

I feel there are also issues with the name. Ansible is moving away from ansible_ssh_user to ansible_user. Setting ssh_port to 5986 for winrm looks weird.

Start by comparing the old and new behavior described for template create.yml, driver.py, instance config, and connection_options. Trace how ssh_user and ssh_port become ansible_user and ansible_port, including the cloud-init and WinRM cases. Done means the parameter behavior and backward-compatibility expectations are clearly documented or specified.

Written by the indexing model from the issue text.