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.
* Wrap funcs to flatten and upload env vars with new func prepareEnvVars.
While the wrapped funcs could be combined, keeping them separate
simplifies testing.
* Configure/refactor std and elevated PS to use new funcs to prepare,
upload and dot source env vars.
* Dot sourcing the env vars in this way avoids the need to embed them
directly in the command string. This avoids the need to escape the env
vars to ensure the command string is correctly parsed.
* Characters within the env vars that are special to PS (such as $'s
and backticks) will still need to be escaped to allow them to be
correctly interpreted by PS.
* The std and elevated PS commands now inject env vars into the remote
env via the same mechanism. This ensures consistent behaviour across the
two command types.
Fixes#5471
Matthew Hooker
stack72
Lawrence
James Nugent
Matt Schreiber
DanHam