* feat (oracle-oci): allow freeform and defined tags to be added to instance (#6313)
* docs (oracle-oci): add descriptions for instance_tags and instance_defined_tags (#6313)
* fix: fmt
* fix: generate hcl2spec
Allows the mounting of additional ISOs when the VM is created. The config option was taken from PR #9055 and slightly changed. Users can specify an array of bus names, bus numbers and filenames.
"cd_drive":[
{
"bus": "ide",
"bus_number": 3,
"filename": "isos:iso/virtio-win-0.1.187.iso"
},
{
"bus": "sata",
"bus_number": 3,
"filename": "isos:iso/someother.iso"
}
]
Closes: #7950
Co-authored-by: Calle Pettersson <carlpett@users.noreply.github.com>
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"
}
]}
```
OblateSpheroid
Rui Lopes
Rémy Léone
Andreas Botzner
Sylvia Moss
packer-ci
Wilken Rivera
Jason Azze
Megan Marsh
Adrien Delorme
Marin Salinas
Viktor A. Danilov
Upo
Larry
Adrien Delorme
raygervais