-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use HCL #1768
Comments
HCL is coming soon 😄 |
@delitescere Is this issue not a duplicate of #283? I noticed you linked to it in the initial post, but it's not clear what the distinction between the two issues is. |
Here unknown keys would be handled differently to how they are now. This proposes "comment-like" keys which are ignored. The comment-ness is indicated by a generally known self-closing comment prefix (viz: It was an alternate suggestion given the larger code change to support comments in non-standard JSON, or JSON5 or YAML or HCL. @sethvargo's comment about the move to support HCL resolves the issue. |
Sorry to bother you, any updates on this? |
It's still coming 😄 |
We decided to delay this a bit, since we don't have an HCL writer yet and we'd like to maintain |
I have drank the HCL kool-aid. 👍 |
Now that https://github.com/hashicorp/hcl exisits, can we get an alternative to json? :) |
@jevonearth that has existed for quite some time 😄. HCL is still coming! |
Since its still coming, is this a good time to feature request include files? see https://github.com/mkheironimus/packergen @jevonearth heres an alternative till add hcl |
still coming soon? |
@mitchellh @sethvargo is this the HCL writer you mentioned: https://github.com/hashicorp/hcl/tree/master/hcl/printer |
Waiting for YAML. Not really into HCL |
It's kind of trivial to wrap packer with a bash function and convert To get you started:
(and the reverse)
|
I already made that. It would be nice to not have to. That's why this ticket exists for HCL
… On Jan 16, 2017, at 12:31 PM, Rickard von Essen ***@***.***> wrote:
It's kind of trivial to wrap packer with a bash function and convert yaml to json.
To get you started:
ruby -r json -r yaml -e "yaml = YAML.load(File.read(\"$1\")); print yaml.to_json"
(and the reverse)
ruby -r json -r yaml -e "json = JSON.parse(File.read(\"$1\")); print YAML::dump(json)"
―
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
HCLHashiCorp needs to show a little faith in itself and use HCL everywhere it can. Either HCL was a good idea and they should run with it, or HCL was a mistake and Terraform is a disaster. Clearly the latter isn't true. So, as a new evaluator/adopter, I have to say that it's cause for concern that these 2 products feel like "two intelligence agencies that don't talk to one another." I'm with @sethvargo. Let's don our direwolf sigil and proclaim that "HCL is coming". (Not only that, also make it happen.) JSONThere is no need to make any changes to shoehorn comments into JSON. The solution was given to us by Douglas Crockford and exemplified by Nicholas Chammas in The Notorious Two Eight Three #283 (comment) YAMLRuby miners love them some YAML and gave us a solution to using it from its inception. This was wonderfully exemplified by Rickard von Essen 2 comments ago #1768 (comment) (though I'd favor using Et ceteraI love that HashiCorp makes it easy to use as many or as few of their products as you need. It fits well with the unix philosophy (as summarized by Peter H. Salus in A Quarter-Century of Unix (1994)):
We should be fine with:JSON$ cat > example.json <<'EOF'
// from: https://www.packer.io/intro/getting-started/vagrant.html
{
// can't we take this out?
"variables": {
"aws_access_key": "", // why is this blank?
"aws_secret_key": "" // ditto
},
"builders": [{
"type": "amazon-ebs",
"access_key": "{{user `aws_access_key`}}",
"secret_key": "{{user `aws_secret_key`}}",
"region": "us-west-2",
"source_ami": "ami-b7a114d7",
"instance_type": "t2.micro",
"ssh_username": "ubuntu",
"ami_name": "packer-example {{timestamp}}",
"tags": {
"created_by": "Packer.io/example"
}
}],
"provisioners": [{
"type": "shell",
"inline": [
"sleep 30",
"sudo apt-get update",
"sudo apt-get install -y redis-server"
]
}],
"post-processors": ["vagrant"]
}
EOF
$ packer validate <(jsmin < example.json)
Template validated successfully. YAML$ cat > example.yaml <<'EOF'
---
# from: https://www.packer.io/intro/getting-started/vagrant.html
# can't we take this out?
variables:
aws_access_key: '' # why is this blank?
aws_secret_key: '' # ditto
builders:
- type: amazon-ebs
access_key: '{{user `aws_access_key`}}'
secret_key: '{{user `aws_secret_key`}}'
region: us-west-2
source_ami: ami-b7a114d7
instance_type: t2.micro
ssh_username: ubuntu
ami_name: packer-example {{timestamp}}
tags:
created_by: Packer.io/example
provisioners:
- type: shell
inline:
- sleep 30
- sudo apt-get update
- sudo apt-get install -y redis-server
post-processors:
- vagrant
EOF
$ packer validate <(ruby -r json -r yaml -e "print YAML.load(ARGF.read).to_json" < example.yaml)
Template validated successfully. |
i'm create small pr for yaml templates, for my limited testing it works fine for me. |
Thank you for the update. We haven't given up on this. |
Thank you @SwampDragons! Given this is actively being worked on, should this issue be reopened? |
Good point; it was accidentally closed when we closed the associated PR without merging. |
Really excited for HCL2 support with packer! |
@SwampDragons Any news on HCL please? |
We're hoping (but not promising) to get it out it with the 1.5.0 release. The team has a working prototype in a branch but it's not polished or hardened yet and with @azr about to be on parental leave we may end up having to slip it a bit later. Goal is by the end of the year, preferably closer to September than December. |
I came back after some years and was surprised this was still open. @SwampDragons Do you have any rough timeframes for when 1.5.0 will be available (even as a beta)? |
If the change is complicated (and there may be very good reasons for that) then isn't it a much lower development risk and cost to leave a perfectly good tool alone and instead, rather than changing the core definition format, provide adapters that convert format-X to JSON? Just a thought. I don't want to trivialise the problem and you may have really important reasons to change the core format but, considering the time and effort that's being spent on this, if it's just about how users define their files then, as a project, is there a need for language adapters like yacker? |
@alanbchristie To be fair, it's not been actively worked on this whole time; it's been a back burner "we should think about this" issue for a very long time, most recently because we wanted to watch and see how the HCL2 rollout went with Terraform 0.12 so we could learn from their process before trying to do it again ourselves. I don't think it will be nearly as arduous a process as it was for Terraform, but I can't speak to the details because like I said it's a project @azr was working on and he's off experiencing parental bliss at the moment. ;) When he gets back I'll ask him if he can write up a little progress update for y'all. |
@NickLarsenNZ The roadmap I show my boss says sometime around October or November. If you want, I can ping you once we have a tryable build. |
I'm new to packer... but i'll be honest, the fact this has been an unaddressed issue for 5-6 years is not only fairly disheartening, but extremely frustrating. Using I could go on for days how json, as implemented by packer, is not suitable to this task, but the fact it doesn't allow comments and encourages code/config duplication (why is it i feel like i need to write a packer json pseudo-compiler to enable config reuse). |
Locked to reduce noise; @azr is back and I'll have him give an update on this issue, including providing beta builds, when he has a chance. |
Hello everyone ! I have some good news 🎉 😃 I recently took quite some time to make the HCL2 move happen and you can find a PR implementing it here: #8423. Some binaries can be found here. The current (old) way of setting up Packer will remain working and we currently plan on fully supporting both versions for a while until we feel confident enough to deprecate the old one. Example hcl filebuild {
sources = [
"source.amazon-ebs.first",
]
provisioner "shell" {
inline = [
"sleep 5"
]
}
post-processor "shell-local" {
inline = [
"sleep 5"
]
}
}
source "amazon-ebs" "first" {
// access_key = "{{user `aws_access_key`}}"
// secret_key = "{{user `aws_secret_key`}}"
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
} PS: docs and variables handling are coming ! |
This is great news @azr, thanks to you and the team. |
WRT: deprecating JSON. |
Is there a json2hcl converter? I have well made packer scripts from Netflix OSS that I would love to convert to HCL. |
Hey everyone, I'm excited about this change ! @darkn3rd I plan on doing a packer specific converter so users can quickly try it without too much copy paste & edit work. @mexisme The HCL library fully understand JSON but the format is changed a little so there is going to need some edits. I will try to have the converter convert a file to JSON too ( or something ). Example hcl filebuild {
sources = [
"source.amazon-ebs.first",
]
provisioner "shell" {
inline = [
"sleep 5"
]
}
post-processor "shell-local" {
inline = [
"sleep 5"
]
}
}
source "amazon-ebs" "first" {
// access_key = "{{user `aws_access_key`}}"
// secret_key = "{{user `aws_secret_key`}}"
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
} New binaries can be found here |
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 } ```
See the following resources: - https://github.com/wakeful/yaml2json - hashicorp/packer#1768
See the following resources: - https://github.com/wakeful/yaml2json - hashicorp/packer#1768
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
It would be great to have YAML (or the HCL) for less cruft and also allow comments. (See #283)
If JSON must be the configuration format, then it would be nice to allow comment-like key/values (perhaps where the names are prefixed with a comment-like glyph). For example:
The text was updated successfully, but these errors were encountered: