When providing a hierarchical output_directory value like
'transient/jenkins-slave', the VM would fail to build in the CreateDisk
step. The properly created output directory would not match the location
provided to CreateDisk, since datastorePath() did not properly split such
paths. Now this case works; tested hierarchical and singular
output_directory values.
Sometimes the AWS API responds that it can't find a newly created
instance if you poll it too soon after creation. Retry a few times
to be sure it really hasn't been created.
Enabling discards for disk can greatly minimize disk size then user
inside vm use fstrim command or trim/discard unneded blocks.
Signed-off-by: Vasiliy Tolstov <v.tolstov@selfip.ru>
This adds retry logic to the amazon/chroot builder. The builder
intermittently fails when ec2conn shows the volume in the attached
state but calling Volumes[0].Attachments return an empty array. The
fix adds a retry logic for when Volumes[0].Attachments has len 0 sleep
for 2 seconds and retry up to 30 times.
When the Volumes[0].Attachments is empty I find within 5 seconds the
Volumes[0].Attachments contains the correct value.
The issue is reported in:
https://github.com/mitchellh/packer/issues/1854
This commit moves the Amazon builders of Packer away from the Hashicorp
fork of the goamz library to the official AWS SDK for Go, in order that
third party plugins may depend on the more complete official library
more easily.
Relates to #1539
AWS is eventually consistent and instance can be not visibile for
some time after creation. This fix eliminates describe-instances
call before going to the proper wait loop
Fixes the following vet report:
builder/vmware/common/step_shutdown_test.go:130: missing argument for Fatalf("%s"): format reads arg 1, have only 0 args
Fixes the following vet reports:
builder/openstack/artifact.go:44: arg a.ImageId for printf verb %d of wrong type: string
builder/openstack/step_wait_for_rackconnect.go:24: arg server for printf verb %s of wrong type: *github.com/mitchellh/gophercloud-fork-40444fb.Server
Fixes the following vet reports:
builder/googlecompute/step_create_instance_test.go:42: possible formatting directive in Fatal call
builder/googlecompute/step_teardown_instance_test.go:29: possible formatting directive in Fatal call
builder/googlecompute/step_teardown_instance_test.go:39: possible formatting directive in Fatal call
Fixes the following vet reports:
builder/digitalocean/builder_test.go:267: arg b.config.SSHUsername for printf verb %d of wrong type: string
builder/digitalocean/builder_test.go:300: arg b.config.RawSSHTimeout for printf verb %d of wrong type: string
builder/digitalocean/builder_test.go:341: arg b.config.RawStateTimeout for printf verb %d of wrong type: string
builder/digitalocean/builder_test.go:382: arg b.config.PrivateNetworking for printf verb %s of wrong type: bool
builder/digitalocean/builder_test.go:397: arg b.config.PrivateNetworking for printf verb %s of wrong type: bool
Fixes the following vet reports:
builder/amazon/common/step_ami_region_copy.go:81: arg target for printf verb %s of wrong type: github.com/mitchellh/goamz/aws.Region
builder/amazon/common/step_ami_region_copy.go:93: arg target for printf verb %s of wrong type: github.com/mitchellh/goamz/aws.Region
This adds two config options that we need in order to successfully build
our Rackspace images.
First, a boolean `rackconnect_wait` option which waits for the
RackConnect metadata to appear.
Second, an `ssh_interface` option, for rackconnect users who have more
prohibitive firewalls on the 'public' interface and want to ensure all
traffic to the server goes over the 'private' one.
Finishes #952.
Change the default behavior from requesting a PTY when executing a
command with the ssh communicator to requesting a PTY only when
configured to do so.
Update the vmware builders to be fully backward compatible with the new
behavior.
These changes permit the use of pre-created SSH keypairs with AWS. If
so, the configuration for the builder needs to include an
ssh_keypair_name option and a ssh_private_key_file.
If ssh_private_key_file is *not* defined, it'll go through the
rigamarole of creating a temporary keypair. The ssh_keypair_name option
by itself won't make that change, because it doesn't make sense to
specify a keypair but not tell packer where the private key is, but it
does happen that you could have a private key and the public-key is
"baked in", and not part of your EC2 account.
Adds a 'ssh_keypair_name' option to the configuration
for AWS, along with some munging to create the
temporarily keypair if one isn't specific.
NOT YET WORKING.
From a 'make' I get the following errors:
builder/amazon/ebs/builder.go:94: b.config.SSHKeyPairName undefined
(type config has no field or method SSHKeyPairName)
builder/amazon/instance/builder.go:199: b.config.SSHKeyPairName
undefined (type Config has no field or method SSHKeyPairName)
The new flow:
1) Provision the instance
2) Tear down the instance, but keep the boot disk
3) Create an image from the disk
4) Tear down the disk
The step to update gcloud is no longer needed, since gceimagebundle isn't used anymore.
Fixes#1507 and addresses https://github.com/mitchellh/packer/issues/1447#issuecomment-61610235.
- help resolve https://github.com/mitchellh/packer/issues/1533
(although timeouts are always ultimately useless in a distributed
system!)
- makes packer no more idempotent or janitorial than before
- derive maximum number of ticks from timeout
- default timeout to 300s (5m) to cater for global AMI copying
- allow user to override with AWS_TIMEOUT_SECONDS environment variable
Given that state fetching is an idempotent operation, a transient
network error should not cause the entire build to fail. Instead,
retry when such errors are encountered.
Previously, any per instance metadata supplied via the GCE builder
was ignored.
Test plan:
- make test
- Manual testing via:
-- Created a packer config that contained a GCE builder with custom
metadata set.
-- Ran `packer build`.
-- Verified the instance had the correct metadata in the GCE console.
This is needed to make 'cdrom0' device unavailable during the ISO installation process.
It is required for some guest OS types, such as FreeBSD and OmniOS.
CD/DVD drive with installation ISO should be exactly the 2nd device in the VM boot order.
This ensures that VM will boot from this ISO at the first boot time only.
For each ISO image the individual cdrom device will be added to the VM. During the cleanup these devices will be deleted.
It makes attach steps more clear - there is no doubt what is the name of the device.
Related to: [mitchellh/packer#1502]
Remove the redundant StepRemoveDevices and rely on the cleanup to be handled by:
* StepAttachParallelsTools.Cleanup
* StepAttachFloppy.Cleanup
* stepAttachISO.Cleanup
We need to ensure the VMWare process has exited before attempting to run VMX file cleanup steps, otherwise VMWare may overwrite our changes. While Packer does its best to ensure VMWare has exited, there's still a race condition on some OSs between VMWare flushing the VMX and Packer updating it. The workaround is to artifically wait 5 seconds.
When using the VMX builder its possible for the source machine to have a floppy and/or CD-ROM mounted which gets cloned to the new VM Packer spins up, but have no Packer configuration for those devices. With this change we always attempt to remove the mounted devices regardless of the Packer configuration.
Once we have produced a qemu VM, we now have the option of using
the vagrant post-processor to create a .box file that can be used with
the vagrant-libvirt plugin.
This uses the new State method of the Artifact API to get necessary
information from the builder.
In order that something consuming an artifact can have access to extra
builder specific data add the State method which allows the caller to
ask for arbitary values by name.
Uses the Python API from Parallels Virtualization SDK to write
boot commands.
This eliminates a 3rd party requirement and makes it easier for people
not using homebrew to get started with packer.
Adds logic to ESXi driver VNC Address function to ignore listen
addresses that bind to localhost (127.0.0.1), this allows certain
default ports to be available on ESXi for VNC connections
When using the VMX builder its possible for the source machine to have a floppy configured which gets cloned to the new VM Packer spins up. When the new VM's Packer config doesn't have a floppy_files config entry, the Packer clean VMX step fails to remove the floppy disk from the new VM. This can cause build failures, for example with the vsphere post processor; generating errors like:
* Post-processor failed: Failed: exit status 1
Error: File (/home/teamcity/tmp/buildTmp/packer941120499) could not be found.
Opening the cloned VM's VMX file you can clearly see it has a floppy entry from the source machine's VMX file (exact same path) even though the Packer config contains no floppy_files entry.