A bug was reported to Joyent, that sometimes packer UI reports that an image was created but it wasn't actually available in Triton for use. We believe that there was a bug uploading that image to Manta but that the metadata of the image was already populated and thus packer was reporting success as it was just checking for the metadata presence
This PR changes Packer to wait for the state of the image to be `active` to make sure that it has fully uploaded and is ready for use
```
==> triton: Stopping source machine (61647c3c-f2bf-4e30-b4bc-f076d3b01522)...
==> triton: Waiting for source machine to stop (61647c3c-f2bf-4e30-b4bc-f076d3b01522)...
==> triton: Creating image from source machine...
==> triton: Waiting for image to become available...
==> triton: Deleting source machine...
==> triton: Waiting for source machine to be deleted...
Build 'triton' finished.
==> Builds finished. The artifacts of successful builds are:
--> triton: Image was created: c2537582-34c7-42ea-bd11-b6ed499d5831
```
This change constructs partial URLs for networks and subnetworks if they
are not already partial or full URLs (i.e., they do not contain a '/' in
their name). Network and subnetwork self-links are no longer retrieved
from the API.
Previously, if a user did not provide the network or subnetwork as a
fully-qualified URL (i.e., self-link), the builder would make
compute.(sub)networks.get API calls with the provided identifier to
discover the self-link. This requires the user or service account Packer
is using to have permission to describe those network resources, which
is becoming less common as IAM is used more. Specifically, a user may
have permission to launch a VM into a network/subnetwork, but will not
have permission to call APIs to describe network resources.
fixes: #5476
Based on this new template addition:
```
{
"variables": {
"image_version": "",
"triton_account": "",
"triton_key_id": "",
"triton_key_material": ""
},
"builders": [{
"type": "triton",
"triton_account": "{{user `triton_account`}}",
"triton_key_id": "{{user `triton_key_id`}}",
"triton_key_material": "{{user `triton_key_material`}}",
"source_machine_package": "g4-highcpu-128M",
"source_machine_image_filter": {
"name": "ubuntu-16.04",
"most_recent": "true"
},
"ssh_username": "root",
"image_version": "{{user `image_version`}}",
"image_name": "teamcity-server"
}],
"provisioners": [
{
"type": "shell",
"start_retry_timeout": "10m",
"inline": [
"sudo apt-get update -y",
"sudo apt-get install -y nginx"
]
}
]
}
```
I got the following output from packer:
```
packer-testing % make image
packer build \
-var "triton_account=stack72_joyent" \
-var "triton_key_id=40:9d:d3:f9:0b:86:62:48:f4:2e:a5:8e:43:00:2a:9b" \
-var "triton_key_material=""" \
-var "image_version=1.0.0" \
new-template.json
triton output will be in this color.
==> triton: Selecting an image based on search criteria
==> triton: Based, on given search criteria, Machine ID is: "7b5981c4-1889-11e7-b4c5-3f3bdfc9b88b"
==> triton: Waiting for source machine to become available...
==> triton: Waiting for SSH to become available...
==> triton: Connected to SSH!
==> triton: Provisioning with shell script: /var/folders/_p/2_zj9lqn4n11fx20qy787p7c0000gn/T/packer-shell797317310
triton: Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
triton: Hit:2 http://archive.ubuntu.com/ubuntu xenial InRelease
```
I can verify from the triton cli tools that the id `7b5981c4` (from the packer output) is indeed the correct ID
```
terraform [master●] % triton images name=~ubuntu-16.04
SHORTID NAME VERSION FLAGS OS TYPE PUBDATE
49b22aec ubuntu-16.04 20160427 P linux lx-dataset 2016-04-27
675834a0 ubuntu-16.04 20160505 P linux lx-dataset 2016-05-05
4edaa46a ubuntu-16.04 20160516 P linux lx-dataset 2016-05-16
05140a7e ubuntu-16.04 20160601 P linux lx-dataset 2016-06-01
e331b22a ubuntu-16.04 20161004 P linux lx-dataset 2016-10-04
8879c758 ubuntu-16.04 20161213 P linux lx-dataset 2016-12-13
7b5981c4 ubuntu-16.04 20170403 P linux lx-dataset 2017-04-03 <------- THIS IS THE LATEST UBUNTU IMAGE
```
This brings packer into the same version of triton-go as that in Terraform, where we rewrote the package from a library with everything in 1 place to individual packages
I was able to successfully provision a machine on triton using this new change, you can find the output in the attached gist
https://gist.github.com/stack72/a64d745459107c5a16bcb156965597ce
via
- create_options: a list of options passed to lxc-create
- start_options: a list of options passed to lxc-start
- attach_options: a list of options passed to lxc-attach
Also extended existing LXC builder BATS tests to exercise the new builder
options, and added website docs.
When running in travis, metadata requests will timeout after 5 seconds.
After 24 such timeouts, we'll hit travis' build timeout of two minutes,
and the build will fail. Lowering it to 100 gets us in a safe time
limit. We _may_ need to expose a timeout env var with this logic,
however.
SwampDragons
stack72
Chris Lundquist
Matthew Hooker
Evan Brown
James Nugent
Lawrence
Matt Schreiber
Joe Ferguson
Mark Meyer
Andrew Pryde
Ben Phegan