- filter build and error checking in Prepare stage (multiErr created in the original function will be returned to Prepare and appended, so all errors show).
- source_image overrides source_image_filter.
- Doc edit
Update website documentation about "floating_ip_network" parameter.
Add new inline comment about alghoritm that is used for checking
floatingIP-related configuration parameters.
Only associate floating IPs if user provided "floating_ip_network" or
"floating_ip".
Remove FindExternalNetwork helper method because it won't be used.
Add support for the external network reference by it's name apart from
ID.
Include external network id in a log message of
the openstack/step_allocate_ip.
Rename "floating_network" to the "floating_ip_network".
Return old "floating_ip_pool" parameter for backward compatibility with
old configuration files. It's value will be passed to the
"floating_ip_network" parameter.
Remove usage of the deprecated OpenStack Compute service floating IP
management and add methods to work with the OpenStack Networking
service floating IPs API.
Remove usage of the deprecated OpenStack Compute service floating IP
pools and add methods to work with the OpenStack Networking service
external networks API.
Move reusable logic of working with the OpenStack Networking service API
to a separate methods in the networking.go file.
Pass error messages from the API services to the ui messages in the
allocate IP step.
Add a step of detaching Compute instance volume if it's created using
the Block Storage service.
It is needed to create a final image.
This commit also moves common volume functions to a different file and
fixes some messages in the StepCreateVolume.
This commit allows user to use the Block Storage v3 volume as the
Compute instance root volume.
Also it adds new volume-related parameters to the builder.
For networks that have multiple subnets, we may want to target a single
subnet. OpenStack doesn't let you target a single subnet in a network
and so you need to make a port.
The new step collects together all the required build artifacts and
places them in the output directory.
* Reintroduce/add the code removed from step export to preserve the
legacy export directory structure when skip_export is unset/false
* Add a place holder for a future function that will move just the VHD
files from the build directory to the output directory when
skip_export is true
* Add tests for current functionality and placeholder tests for future
functions
The export process now exports the VM directly from the build directory
into the output directory. There are no intermediate steps or copying of
files involved. This means that there is no longer any benefit in having
a separate directory to house the VHD files - see #5206 for the
reasoning behind the introduction of this feature.
If a user wishes to house the build files on a separate disk from the
output directory (perhaps for performance reasons or due to disk space
limitations) they can still do so through the use of `temp_path`.
PR #5631 introduced code to build/create disks directly in the output
directory if `skip_export` was set in an attempt to optimise the build
process. These are no longer required.
* Report compaction results
* Failure to find any disks under the supplied path is treated as a
'soft' error and a warning message will be printed in place of the
compaction result. Any other failure will cause the build to fail.
Commit 3fc2defb6 altered the directory structure associated with an
exported VM. The changes mean that the export process now stores the
exported machine files and folders under a folder with name 'vm_name' in
the output directory.
This commit restores the previous behaviour whereby the exported machine
files and folders were stored directly in the output directory. This
allows us to keep the efficiency improvements introduced with 3fc2defb6
while maintaining backward compatibility.
By default the Export-VM command creates three folders in the specified
export directory - 'Virtual Hard Disks', 'Virtual Machines' and
'Snapshots'. When a machine with no associated snapshots is exported the
'Snapshots' directory is empty.
Prior to 3fc2defb6 the Snapshots folder was not copied/incorporated into
the output directory at all. This was a bug.
This commit preserves the legacy behaviour by not including an empty
Snapshots directory in the export. However, if there *are* Snapshots
associated with the VM, they are now moved into the output directory
along with the usual directories containing disks and VM metadata. This
prevents warnings/errors on import due to missing snapshots.
* Fixes a bug that caused the build to error if users did not
explicitly set `skip_compaction:true` when setting `skip_export:
true`. See #6392.
* Improves the efficiency of the compaction and export process by
reordering the compaction and export steps.
* Further improves the efficiency of the compacting step through
compacting the vmd* file directly rather than creating and then
operating on a copy.
* The changes mean the export process now stores the exported machine
files and folders under a folder with name 'vm_name' in the output
directory. Previously the exported machine files and folders were
stored directly in the output directory.
This adds a new parameter to the EBS builders named `spot_tags'. This
parameter accepts a map of tags, much like `tags'. These tags will be
applied to a spot request that is created.
Improve visibility.
The value in the Name field returned by 'esxcli network vm list'
actually returns the VMs `displayName`. As such, we need to match
against `displayName` to discover the VMs 'WorldID'.
'WorldId' is ultimately used/needed as an argument in the command that
returns the VMs IP.
The value of displayName is needed by later steps:
* When determining the IP address of the build VM
* When exporting the VM using ovftool
By default Packer will configure the VMX so `displayName` is equal to
the value defined for `vm_name` in the build template. However, it is
possible (and sometimes desirable) to set a custom value for
`displayName`.
Users can set a custom `displayName` through use of the `vmx_data`
option in their template.