* fix random nil pointer dereference I found while debugging hcl2_upgrade issues
* fix hcl2_upgrade command by creating passthroughs for all text template fields
The oci api returns 429, among others in case a per-user rate limit is
hit. Currently our only mechanism to deal with this is to wait 5s
between the requests that poll for image availability (and export).
With a custom retry strategy we can handle more error situations while
putting less load on the api.
* fix ubuntu json template example
* add hcl template example
* add hcl alpine example
* add hcl versions of alpine and macos; update macos json
* add hcl version of windows template, call fix on windows json
This adds the new `required_plugins` block to be nested under the packer block.
Example:
```hcl
packer {
required_plugins {
aws = {
version = ">= 2.7.0"
source = "azr/aws"
}
azure = ">= 2.7.0"
}
}
```
For example on darwin_amd64 Packer will install those under :
* "${PACKER_HOME_DIR}/plugin/github.com/azr/amazon/packer-plugin-amazon_2.7.0_x5.0_darwin_amd64"
* "${PACKER_HOME_DIR}/plugin/github.com/hashicorp/azure/packer-plugin-azure_2.7.0_x5.0_darwin_amd64_x5"
+ docs
+ tests
It is being printed after it is created so we need to mock it to prevent
a nil pointer dereference when the tests are run with the launch
template create request is mocked.
* Set the QEMU builder vnc_port_min to have a minimum value of 5900,
with updated documentation to explain why.
* Changed output messages so that the correct port is listed in packer's
messaging to the user.
LONGER DESCRIPTION
If vnc_min_port is set to anything above 5900, then packer will fail to
connect via VNC to the QEMU instance. This is due to how QEMU parses
the port for listening to VNC:
host:d
TCP connections will only be allowed from host on
display d. By convention the TCP port is 5900+d.
Previously the calculation for the port was vncPort - VNCPortMin,
however this will result in an incorrect port being displayed in
packer's messages and potentially packer being unable to connect via VNC
to the host.
For example if vnc_port_min=5990 nad vnc_port_max=5999:
```
Looking for available port between 5990 and 5999 on 0.0.0.0
Found available port: 5996 on IP: 0.0.0.0
Found available VNC port: 5996 on IP: 0.0.0.0
[....]
==> Starting VM, booting disk image
view the screen of the VM, connect via VNC without a password to
vnc://0.0.0.0:6
```
This will cause QEMU to set the listening port to 5906 while packer's
VNC client is attempting to connect to 5996.
I am a touch concerned as this commit undoes pull request #9905
(specfically commit 7335695c), but I am also confused as to how he was
able to get QEMU to get a VNC listening port below 5900, as examining
QEMU's git history has shown that this behavior has been in since at
least 2017, probably older.
Hopefully the more explicit error messaging and documentation can make
it clear why this is being undone.
Some instances of VMWare will not generate the networkmapping configuration (netmap.conf)
at the time of installation. To deal with this issue, we check for the networkmapping file
first, and then fallback to the networking file which also might exist and contain the
interface information that we require.
This fixes issue #10009.
