# Description
The output of the example on [uuidv4 Function](https://developer.hashicorp.com/packer/docs/templates/hcl_templates/functions/uuid/uuidv4) is not a valid RFC compliant UUIDv4. It indicates the usage of the `uuidv4()` function and outputs `b5ee72a3-54dd-c4b8-551c-4bdc0204cedb` which is not a valid UUIDv4.
I've corrected the example to output a UUIDv4 conforming to the RFC as such `xxxxxxxx-xxxx-4xxx-Nxxx-xxxxxxxxxxxx`, where:
- The 13th character is always `4` (indicating version 4).
- The 17th character must be either `8`, `9`, `a`, or `b` (indicating the first character of the variant).
# Changes
```diff
- b5ee72a3-54dd-c4b8-551c-4bdc0204cedb
+ 9fc99a70-7cd5-482d-bb2b-03af016e4e94
```
Replaces the old UUID output with a valid RFC compliant UUIDv4.
# References
- [RFC 4122](https://datatracker.ietf.org/doc/html/rfc4122)
- [RFC 9562](https://datatracker.ietf.org/doc/html/rfc9562)
# Misc.
To make sure this wasn't an issue with the `uuidv4()` function within Hashicorp's [packer](https://github.com/hashicorp/packer) I tested the function in the following way:
### Command executed:
```ps
> .\packer.exe inspect .\uuid.pkr.hcl
```
### Contents of the _uuid.pkr.hcl_ file:
```hcl
locals {
uuid_0 = uuidv4()
uuid_1 = uuidv4()
uuid_2 = uuidv4()
uuid_3 = uuidv4()
uuid_4 = uuidv4()
uuid_5 = uuidv4()
uuid_6 = uuidv4()
uuid_7 = uuidv4()
uuid_8 = uuidv4()
uuid_9 = uuidv4()
}
```
### Output:
```ps
Packer Inspect: HCL2 mode
> input-variables:
> local-variables:
local.uuid_0: "90877db8-5519-46ea-ae15-7dfb92594064"
local.uuid_1: "fe6a4649-97d9-4686-b981-3295175f941a"
local.uuid_2: "9944d83d-dab2-4cfb-a1db-572d19271e7a"
local.uuid_3: "547cddb7-c979-4b87-90d0-2bd9b68858b5"
local.uuid_4: "c13dc47a-552c-4dfb-a75d-2f63bb248b41"
local.uuid_5: "3db1ce29-bdde-4642-b010-1a41d47c22a3"
local.uuid_6: "4a020460-edd1-471d-b8a2-5956c0c68257"
local.uuid_7: "1845bf87-6908-4fc0-8f11-b5b4f36c60a7"
local.uuid_8: "f5c7e552-b799-45f3-8172-46162eadfd89"
local.uuid_9: "057c2eaf-6769-4a8d-90c8-775aec80496a"
> builds:
```
* Document use of TMPDIR required for remote plugin installation
* Update website/content/docs/configure.mdx
Co-authored-by: Lucas Bajolet <105649352+lbajolet-hashicorp@users.noreply.github.com>
---------
Co-authored-by: Lucas Bajolet <105649352+lbajolet-hashicorp@users.noreply.github.com>
Updates the provisioners documentation for a better reader experience by including a list of the built-in provisioners and a link to the community supported provisioners that are all withing the navigation tree.
Ref: #12898
Signed-off-by: Ryan Johnson <ryan@tenthirtyam.org>
Adds an example of a string template being used.
The example demonstrates how a template sequence can be used to embed the value of a variable into a string that can be used as script content.
Ref: #12651
Signed-off-by: Ryan Johnson <ryan.johnson@broadcom.com>
Adds documentation for `ssh_keypair_name`, `ssh_agent_auth`, `temporary_key_pair_name`, and `ssh_private_key_file`.
The note is updated noting that not all builders support these options.
Ref: #10722
Signed-off-by: Ryan Johnson <ryan@tenthirtyam.org>
* docs: add plugin loading spec documentation
The logic for discovering and loading plugins is not well documented on
the current documentation.
This causes issues for users that have to troubleshoot why a particular
plugin cannot be found or installed, so this commit adds a specification
document, detailing what are Packer's expectations when it comes to
discovering plugins.
* Apply suggestions from code review
* Update plugin loading specification navbar
---------
Co-authored-by: Wilken Rivera <dev@wilkenrivera.com>
Compared to Terraform, Packer was lacking a capability to encode/decode
strings to/from base64-encoded text encoded with another encoding.
This could be problematic in some cases, mainly when working with
Windows, as most of the OS uses UTF-16LE as its standard encoding for
many operations.
Therefore, we take a page from Terraform here, and add those functions
to what Packer supports in an HCL2 context.
When updating the docs in prevision for Packer 1.11.0, we changed the
templates that show how plugins are installed/discovered with commands
like packer init.
While doing so, a template had its component renamed to coolcloud, but
the following prose did not change, making the text inconsistent.
Since there are other mentions of myawesomecloud in the codebase, we
choose to settle on this one for that example too.
Since the plugins install subcommand can install both remotely and
locally sourced plugins, we update the documentation for it on the
web-docs to reflect this change.
Since we're changing how packer manages plugin installation with 1.11.0,
we reflect those changes to the website documentation.
Now, we only describe the packer init and packer plugins install
commands, along with the `--path` flag for installing from a local
source.
The explanations of how packer discovers and picks which version of a
plugin to load are also included, along with the list of constraints
that determine whether a plugin can be considered or not to be loadable.
With the changes coming up for 1.11.0, we update the Packer
configuration docs so they describe the one way to load plugins, and the
two environment variables which can be set to change this behaviour.
In the full example for both the hcp-packer-artifact and
hcp-packer-version the hcp-packer-version reference in the example
template was mistakenly spelled as "hcp_packer_version", which won't
work, so we fix that typo here.
