* 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
* Update and pin dependencies
* Update NextJS Scripts
* npm run lint
* npm run format
* docs generator: indent docs by two and make spacing better
Co-authored-by: Adrien Delorme <azr@users.noreply.github.com>
By default the Google builder will wrap any provided startup script file
in order to track its execution via custom metadata. The wrapper script
can add a bit of complexity to the start script file so a new option is
being added `wrap_startup_script`. This option allows a user to disable
the script wrapping and just let GCE do its own thing when executing a
startup script.
* Drop the iso_checksum_type & iso_checksum_url fields
In favor of simply using iso_checksum that will know what to do.
* fix after master merge
* Update builder_test.go
* Update builder_test.go
* Update builder_test.go
* Update builder_test.go
* Update builder_test.go
* remove checksum lowercasing tests
* Update builder_test.go
* Update builder_test.go
* better docs
* Update builder_test.go
* even better docs
* Update config.go
* Update builder_test.go
* Update step_create_vmx_test.go
* make generate
* better docs
* fix imports
* up tests
* Update _ISOConfig-required.html.md
* Update builder_test.go
* don't use sha1.Sum("none") as a caching path
* Update builder_test.go
* better docs
* Update iso_config_test.go
remove ISOChecksumType/ISOChecksumURL references
* Update step_download_test.go
* add iso_checksum_url and iso_checksum_type fixers + tests
* add concrete examples of checksum values
* add examples of checksumming from local file
* update go-getter dep
* up deps
* use new go-getter version
* up ESX5Driver.VerifyChecksum: use go-getter's checksumming
* ISOConfig.Prepare: get checksum there in case we need it as a string in ESX5Driver.VerifyChecksum
* Update iso_config.go
* get go-getter from v2 branch
* Update driver_esx5.go
add more comments
* Update driver_esx5.go
* show better error message when the checksum is invalid
* Update builder_test.go
put in a valid checksum to fix tests, checksum is md5("packer")
* Update builder_test.go
test invalid and valid checksum
* more test updating
* fix default md5 string to be a valid md5
* TestChecksumFileNameMixedCaseBug: use 'file:' prefix for file checksumming
* Update iso_config_test.go
* Update iso_config_test.go
* Update builder_test.go
* Update builder_test.go
* Update builder_test.go
* Update CHANGELOG.md
* Update CHANGELOG.md
* Update go.mod
* Update go.mod
* Update CHANGELOG.md
This change fixes an issue where using the `disk_additional_size` configuration option would cause builds to fail.
Build results before the change
```
==> Builds finished but no artifacts were created.
Build 'azure-arm' errored: Code="DeploymentFailed" Message="At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details." Details=[{"code":"BadRequest","message":"{\r\n \"error\": {\r\n \"code
\": \"InvalidParameter\",\r\n \"message\": \"The entity name 'dataDisk.name' is invalid according to its validation rule: ^[^_\\\\W][\\\\w-._]{0,79}(?\u003c![-.])$.\",\r\n \"target\": \"dataDisk.name\"\r\n }\r\n}"}]
```
Build results after change
```
Build 'azure-arm' finished.
==> Builds finished. The artifacts of successful builds are:
--> azure-arm: Azure.ResourceManagement.VMImage:
OSType: Linux
ManagedImageResourceGroupName: test-pkr
ManagedImageName: wilkenPacker9249
```
Closes#9249
Richard Turc
Sylvia Moss
Troy Lindsay
GennadySpb
Jason Azze
Megan Marsh
Adrien Delorme
ntoofu
Li Kexian
Chris Chilvers
piggona
Adrien Delorme
Michael Kuryshev
Joshua Foster
Jonathan Neal
Wei Cheng
Wilken Rivera
Lyle Franklin
Adam Dobrawy
mingsheng.su
Conlan
Paul Meyer
Jeff Escalante
Feiyu Shi
Rui Lopes