You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was suggested in #11164 (comment) that the -hcl2-strict parameter should default to false and be configurable via an environment variable in order to not break the parsing of existing jobs/var-files which contain undeclared variables. However, this wasn't addressed before #11284 was merged; that PR originally defaulted to false but it was changed to true in 91061ae.
Reproduction steps
Executing the following without setting -hcl2-strict=false using a vars.hcl file that contains variables not declared in job.nomad:
nomad job validate -var-file=vars.hcl job.nomad
Expected Result
The job should validate successfully (this was the case before v1.2.0)
Actual Result
An "Undefined variable" error is returned.
The feature is a fine one, but unfortunately it caused a breaking change in a minor release. In our system, we typically define common variables for a region in a file, even if they're used only by some of the jobs deployed in that region; that is, we relied on the behaviour of -hcl2-strict=false.
I personally would prefer -hcl2-strict=false to be the default, although I've seen discussions here that argue the other way. Barring that, allowing this to be configured via an environment variable would allow us to maintain the previous behaviour with fewer changes to our scripts and workflow.
The text was updated successfully, but these errors were encountered:
@adeschamps it looks like this is coming from b52f42d which landed in 1.2.0. Unfortunately the 1.2.0 Upgrade Guide doesn't call this out, so that's absolutely a documentation fix we need. While I can see an argument for it either way, we definitely intended for strict to be the default behavior.
it caused a breaking change in a minor release
Just for clarity, we make breaking changes in "minor" releases with some frequency (although we're always forward-compatible at the data store level). I don't think we have a public versioning stance, but generally speaking we backport patches to two minor versions (and honestly you may see us refer to those as "major" versions just because we're an application not a library so semver doesn't really apply here). Ex. fixes for 1.2.3 got backported to 1.1.9 and 1.0.15.
I'm going to lock this issue because it has been closed for 120 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.
Nomad version
Nomad v1.2.3
Operating system and Environment details
Arch Linux
Issue
It was suggested in #11164 (comment) that the
-hcl2-strict
parameter should default tofalse
and be configurable via an environment variable in order to not break the parsing of existing jobs/var-files which contain undeclared variables. However, this wasn't addressed before #11284 was merged; that PR originally defaulted tofalse
but it was changed totrue
in 91061ae.Reproduction steps
Executing the following without setting
-hcl2-strict=false
using avars.hcl
file that contains variables not declared injob.nomad
:Expected Result
The job should validate successfully (this was the case before v1.2.0)
Actual Result
An "Undefined variable" error is returned.
The feature is a fine one, but unfortunately it caused a breaking change in a minor release. In our system, we typically define common variables for a region in a file, even if they're used only by some of the jobs deployed in that region; that is, we relied on the behaviour of
-hcl2-strict=false
.I personally would prefer
-hcl2-strict=false
to be the default, although I've seen discussions here that argue the other way. Barring that, allowing this to be configured via an environment variable would allow us to maintain the previous behaviour with fewer changes to our scripts and workflow.The text was updated successfully, but these errors were encountered: