I've tested the behavior of CPUs and cpu_cores against both vSphere 5.5 and 6.7. In both cases, CPUs gives you virtual cores, not sockets.
For example, I want 6 cores per socket across 2 sockets for 12 total cores. Based on the wording of this doc, I set CPUs to 2 and cpu_cores to 6. The documentation implies that will give me 2 sockets with 6 cores each. The actual behavior is you get 2 cores, and when you crack open the VMs configuration, you see that cores per socket is set to 6 -- which is meaningless.
Setting CPUs to 12 and cpu_cores to 6 gives me what I wanted. So the wording I propose is
```
- `CPUs` (int32) - Number of CPU cores.
```
Before change
```
Usage: packer [--version] [--help] <command> [<args>]
Available commands are:
build build image(s) from template
console creates a console for testing variable interpolation
fix fixes templates from old versions of packer
hcl2_upgrade build image(s) from template
inspect see components of a template
validate check that a template is valid
version Prints the Packer version
```
After change
```
Usage: packer [--version] [--help] <command> [<args>]
Available commands are:
build build image(s) from template
console creates a console for testing variable interpolation
fix fixes templates from old versions of packer
hcl2_upgrade transform a JSON template into a HCL2 configuration
inspect see components of a template
validate check that a template is valid
version Prints the Packer version
```
when it encounters map[string]interface{} or []interface{} types, hcl2_upgrade now takes the 'most complex' entry from those in order to tell wether this is going to be a body `body {}` or an attribute `attribute = {}`. Before that the hcl2_upgrade command could be a bit random there.
A way better ( but may be somewhat hard ) way to do this would be to use the actual plugins structs in order to generate the HCL2.
Refactor step_export and the driver interface to move the ovftool call
into the vmware driver. This refactor allows us to add meaningful tests
to step_export, which I have also added here.
withouth this fix we would have had to do
```hcl
temporary_iam_instance_profile_policy_document {
statement {
action = ["*"]
effect = "Allow"
resource = ["*"]
}
version = "2012-10-17"
}
```
instead of the same document but with capitalised fields
hcl2_upgrade transforms a JSON build-file in a HCL2 build-file.
This starts a validated Packer core and from that core we generate an HCL 'block' per plugin/configuration. So for a builder, a provisioner, a post-processor or a variable. The contents of each block is just transformed as is and basically all fields are HCL2-ified.
A generated field can be valid in JSON but invalid on HCL2; for example JSON templating (in mapstructure) allows to set arrays of strings - like `x = ["a", "b"]` - with single strings - like `x="a"` -, HCL does not allow this.
Since JSON does not make the distinction between variables and locals, everything will be a variable. So variables that use other variables will not work.
hcl2_upgrade tries to transform go templating interpolation calls to HCL2 calls when possible, leaving the go templating calls like they are in case it cannot.
Work:
* transpiler
* tests
* update hcl v2 library so that output looks great.
* update docs
PutRolePolicy & AddRoleToInstanceProfile are eventually consistent but it is not possible to wait for them to be done here: 0785c2f6fc/builder/amazon/common/step_iam_instance_profile.go (L117-L134) which was causing the `CreateFleet` to fail (100% for me). So for now we retry a bit later. Waiting 5 seconds after the previously linked code also fixed this.
Test file:
```json
{
"builders": [
{
"type": "amazon-ebs",
"region": "eu-west-1",
"ami_name": "ubuntu-16.04 test {{timestamp}}",
"ami_description": "Ubuntu 16.04 LTS - expand root partition",
"source_ami_filter": {
"filters": {
"virtualization-type": "hvm",
"name": "ubuntu/images/*/ubuntu-xenial-16.04-amd64-server-*",
"root-device-type": "ebs"
},
"owners": [
"099720109477"
],
"most_recent": true
},
"spot_price": "0.03",
"spot_instance_types": [
"t2.small"
],
"encrypt_boot": true,
"ssh_username": "ubuntu",
"ssh_interface": "session_manager",
"temporary_iam_instance_profile_policy_document": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"*"
],
"Resource": "*"
}
]
},
"communicator": "ssh"
}
]}
```
This changes updates the AWS Secrets manager session authentication
logic to support reading the AWS configuration file for default
credentials and region settings, if they are not provided via
environment variables.
* Modify error output a little to remove stutter "error ... : error ...`
Results before change
```
unset AWS_REGION
⇶ ~/pkg/packer build amazon-ebs_secretsmanager_shell-local.json
template: root:1:3: executing "root" at <aws_secretsmanager `packer/test/keys`
`shell`>: error calling aws_secretsmanager: Error getting secret: MissingRegion:
could not find region configuration
```
Results after change
```
unset AWS_REGION
⇶ ~/pkg/packer build amazon-ebs_secretsmanager_shell-local.json
null: output will be in this color.
==> null: Running local shell script: /tmp/packer-shell721444992
null: powershell
Build 'null' finished after 4 milliseconds 121 microseconds.
==> Wait completed after 4 milliseconds 192 microseconds
==> Builds finished. The artifacts of successful builds are:
```
packer-ci
Jason Azze
Wilken Rivera
Megan Marsh
Adrien Delorme
Viktor A. Danilov
Upo
Larry
Adrien Delorme
raygervais
Sylvia Moss