Skip to content
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

Allow disabling hcl2 interpolation for string literals #10777

Closed
notnoop opened this issue Jun 17, 2021 · 2 comments
Closed

Allow disabling hcl2 interpolation for string literals #10777

notnoop opened this issue Jun 17, 2021 · 2 comments
Labels
stage/accepted Confirmed, and intend to work on. No timeline committment though. stage/duplicate theme/hcl type/enhancement

Comments

@notnoop
Copy link
Contributor

notnoop commented Jun 17, 2021

HCLv2 added more comprehensive support for expression interpolation within strings. Users can insert variable references (e.g. ${var.user_field}) or expressions in here-doc style syntax:

template = <<EOT
%{ for ip in var.ips }
server ${ip}
%{ endfor }
EOT

This interpolation though comes with downsides. Nomad templates frequently embed shell/perl scripts or embedded nijna-like templates that can conflict with the use of ${ or %{. Users must escape references of ${ and %{, a tedious task, specially for users upgrading from pre-1.0.0 nomad versions.

We should consider adding a mechanism to disable HCLv2 interpolation processing; e.g. adopt the bash heredoc mechanism to disable variables, by using ', e.g. <<'EOF'.

The change needs to be coordinated with the hcl library.

This issue was raised in #10743 and #9838 (comment) .

@notnoop notnoop added type/enhancement theme/hcl stage/accepted Confirmed, and intend to work on. No timeline committment though. labels Jun 17, 2021
notnoop pushed a commit that referenced this issue Jul 26, 2021
Support the new post-1.0.0 job spec fields in the HCLv1 parser.

The HCLv1 parser is still the default (or only!) parser in many downstream tools, e.g. [Levant](https://github.com/hashicorp/levant/blob/e48c439f14def83b0cbe24c2553e90e959474f16/template/render.go#L13-L30), and [terraform-provider-nomad](https://github.com/hashicorp/terraform-provider-nomad/blob/bce32a783176c7943ac662a3eee48b76d92c4d6a/nomad/resource_job.go#L735-L743) .

While we initially intended to deprecate HCLv1 parser in 1.0.0, we never communicated that publicly. We did not fully anticipate the public usage of `jobspec` package (we assumed it's a private package), or the friction that HCLv2 introduced in some cases (e.g. #10777, #9838).

So moving forward we intend to ensure that new job spec fields are honored in both the HCLv1 and HCLv2 parser until we solidify the migration path and communicate it properly.
@idrennanvmware
Copy link
Contributor

@notnoop - just wanted to follow up if there had been any further movement on this? We're still stuck on HCL1 jobs and getting deeper and deeper in to having a hard time switching to HCL2 without this kind of feature

Thanks!

@tgross
Copy link
Member

tgross commented Aug 16, 2024

I'm going to close this issue as a duplicate of #9838. I've left some notes there recently on the challenge involved in implementing this, which will likely require upstream changes to HCL syntax.

@tgross tgross closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stage/accepted Confirmed, and intend to work on. No timeline committment though. stage/duplicate theme/hcl type/enhancement
Projects
None yet
Development

No branches or pull requests

3 participants