Since the work to mount isos was duplicated already across the
step_mount_iso and step_mount_guest_additions, this required a
refactor to prevent further code duplication and make the
ports and devices easier to follow
tooling. Tested on OSX, `Windows, and Linux. Documented command line dependencies.
Added acceptance tests (behind testacc flag, since there are dependencies).
This option is only implemented for the vmware and hyperv iso builders. It will be
implemented for others in later PRs in order to make review easier.
* Separate Access Config from yandex builder Config
* make use of Access Config explicit
* Move `MaxRetries` into AccessConfig
* NewDriverYC use AccessConfig instead Config
* yandex-import PP use common Access Config
Now support set custom API Endpoint
* yandex-export PP use common Access Config
Now support set custom API Endpoint too (as yandex-import)
* fix test
* Tiny doc updates.
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.
```
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
Adrien Delorme
Megan Marsh
Niels Pardon
Sylvia Moss
Adrien Delorme
Rui Lopes
Patrik
Richard Turc
Artis3n
Troy Lindsay
GennadySpb
Jason Azze
Larry