* mapstructure-to-hcl2: when we see a map generate an attribute spec and not a block spec
this will alow to do
tags = {
key = "value"
}
instead of
tags {
key = "value"
}
This will also enable using variables directly for those tags
* generate code
* update tests
This follows #8232 which added the code to generate the code required to parse
HCL files for each packer component.
All old config files of packer will keep on working the same. Packer takes one
argument. When a directory is passed, all files in the folder with a name
ending with “.pkr.hcl” or “.pkr.json” will be parsed using the HCL2 format.
When a file ending with “.pkr.hcl” or “.pkr.json” is passed it will be parsed
using the HCL2 format. For every other case; the old packer style will be used.
## 1. the hcl2template pkg can create a packer.Build from a set of HCL (v2) files
I had to make the packer.coreBuild (which is our one and only packer.Build ) a public struct with public fields
## 2. Components interfaces get a new ConfigSpec Method to read a file from an HCL file.
This is a breaking change for packer plugins.
a packer component can be a: builder/provisioner/post-processor
each component interface now gets a `ConfigSpec() hcldec.ObjectSpec`
which allows packer to tell what is the layout of the hcl2 config meant
to configure that specific component.
This ObjectSpec is sent through the wire (RPC) and a cty.Value is now
sent through the already existing configuration entrypoints:
Provisioner.Prepare(raws ...interface{}) error
Builder.Prepare(raws ...interface{}) ([]string, error)
PostProcessor.Configure(raws ...interface{}) error
close#1768
Example hcl files:
```hcl
// file amazon-ebs-kms-key/run.pkr.hcl
build {
sources = [
"source.amazon-ebs.first",
]
provisioner "shell" {
inline = [
"sleep 5"
]
}
post-processor "shell-local" {
inline = [
"sleep 5"
]
}
}
// amazon-ebs-kms-key/source.pkr.hcl
source "amazon-ebs" "first" {
ami_name = "hcl2-test"
region = "us-east-1"
instance_type = "t2.micro"
kms_key_id = "c729958f-c6ba-44cd-ab39-35ab68ce0a6c"
encrypt_boot = true
source_ami_filter {
filters {
virtualization-type = "hvm"
name = "amzn-ami-hvm-????.??.?.????????-x86_64-gp2"
root-device-type = "ebs"
}
most_recent = true
owners = ["amazon"]
}
launch_block_device_mappings {
device_name = "/dev/xvda"
volume_size = 20
volume_type = "gp2"
delete_on_termination = "true"
}
launch_block_device_mappings {
device_name = "/dev/xvdf"
volume_size = 500
volume_type = "gp2"
delete_on_termination = true
encrypted = true
}
ami_regions = ["eu-central-1"]
run_tags {
Name = "packer-solr-something"
stack-name = "DevOps Tools"
}
communicator = "ssh"
ssh_pty = true
ssh_username = "ec2-user"
associate_public_ip_address = true
}
```
* I had to contextualise Communicator.Start and RemoteCmd.StartWithUi
NOTE: Communicator.Start starts a RemoteCmd but RemoteCmd.StartWithUi will run the cmd and wait for a return, so I renamed StartWithUi to RunWithUi so that the intent is clearer.
Ideally in the future RunWithUi will be named back to StartWithUi and the exit status or wait funcs of the command will allow to wait for a return. If you do so please read carrefully https://golang.org/pkg/os/exec/#Cmd.Stdout to avoid a deadlock
* cmd.ExitStatus to cmd.ExitStatus() is now blocking to avoid race conditions
* also had to simplify StartWithUi
- Add guest os type to change the default Chef-Solo and Chef-Client provisioner behavior. Paths, commands etc.
- Change Chef installation download location to chef.io domain
- Add encrypted data bag secret configuration
Since the chef-client provisioner is cleaning the node and client at the chef-server from the provisioned node
it needs to have a flexible configuration
This is replacing the used knife flags: -s '<chef-server-url>' -k '/tmp/packer-chef-client/client.pem' -u '<client-name>'
and puts their values into a generated knife.rb
Additionally the knife.rb may include the optional ssl_verify_mode attribute to enable the verify mode verify_none
Background:
When deleting node and client to a self-hosted chef-server using self signed cerfiticates the usage of
knife node delete <node-name> -y -s '<chef-server-url>' -k '/tmp/packer-chef-client/client.pem' -u '<client-name>'
will lead into a ssl verification failure.
The error output of the knife call is somthing like:
2015/06/24 12:29:17 ui: docker: WARNING: No knife configuration file found
docker: WARNING: No knife configuration file found
2015/06/24 12:29:17 ui: docker: ERROR: SSL Validation failure connecting to host: 172.16.117.63 - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed
docker: ERROR: SSL Validation failure connecting to host: 172.16.117.63 - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
2015/06/24 12:29:17 ui: docker: ERROR: Could not establish a secure connection to the server.
docker: ERROR: Could not establish a secure connection to the server.
2015/06/24 12:29:17 ui: docker: Use 'knife ssl check' to troubleshoot your SSL configuration.
docker: Use 'knife ssl check' to troubleshoot your SSL configuration.
2015/06/24 12:29:17 ui: docker: If your Chef Server uses a self-signed certificate, you can use
docker: If your Chef Server uses a self-signed certificate, you can use
2015/06/24 12:29:17 ui: docker: 'knife ssl fetch' to make knife trust the server's certificates.
docker: 'knife ssl fetch' to make knife trust the server's certificates.
2015/06/24 12:29:17 ui: docker:
docker:
2015/06/24 12:29:17 ui: docker: Original Exception: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
docker: Original Exception: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
2015/06/24 12:29:17 packer-builder-docker: 2015/06/24 12:29:17 Executed command exit status: 100
