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
Is your feature request related to a problem? Please describe.
The ip_address profile parameter is used only to connect to the newly created guest over SSH post-creation. Its naming is confusing and suggests that the IP address on the guest is set this way; it is not (see the net0,1,2 etc params).
Additionally the other SSH related parameters (username/password) are prefixed with ssh_
Describe the solution you'd like
All SSH parameters should be clearly marked as such, e.g. with an ssh_ prefix
All parameters used internally by salt should be clearly separated from those transmitted to the API, possibly in two separate trees instead of in a single unclear jungle:
API parameters. Users should be guided towards the Proxmox API documentation to find out more. Currently any change in the API requires documentation changes in salt, this is not what we want
Non-API parameters. Users should be told by the salt documentation what parameters (such as SSH) can be configured
Perhaps eventually something like this? Not sure how other providers do this:
myprofile:
provider: proxmox
# Connect after install: the old ssh_username, ssh_password and ip_address parameters
ssh:
username: johndoe
password: secret
host: test.example.com
# Guest parameters
guest:
memory: 2048
net0: virtio,ip=dhcp
Describe alternatives you've considered
Params in a single tree with clear names or separated in two trees
The text was updated successfully, but these errors were encountered:
The ip_address is not only used for the ssh connection.
OpenVZ uses this as an optional parameter in the Proxmox API and LXC maps it to net0 parameter in the Proxmox API.
Take a closer look at the create_node() function:
Is your feature request related to a problem? Please describe.
Describe the solution you'd like
Perhaps eventually something like this? Not sure how other providers do this:
Describe alternatives you've considered
Params in a single tree with clear names or separated in two trees
The text was updated successfully, but these errors were encountered: