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

unexpected behavior with docker -> volume_options and hcl2 #9604

Closed
MorphBonehunter opened this issue Dec 10, 2020 · 4 comments
Closed

unexpected behavior with docker -> volume_options and hcl2 #9604

MorphBonehunter opened this issue Dec 10, 2020 · 4 comments
Assignees
Labels
stage/accepted Confirmed, and intend to work on. No timeline committment though. theme/hcl type/bug type/question

Comments

@MorphBonehunter
Copy link

Nomad version

Nomad v1.0.0 (cfca640)

Operating system and Environment details

ArchLinux

Issue

The docker "volume_options" parameter and sub-parameter which are mentioned in the Docs doesn't work with the hcl2 parser in the form mentioned there.
This happens to me after upgrading to 1.0 of nomad and try to resubmit an existing job with this option.
I can use the -hcl1 option and it works but the mentioned fix for not using this option isn't appropriate.

Reproduction steps

  • upgrade nomad to v1.0
  • re-submit an job with the docker volume_options set

Job file (if appropriate)

original job file sniped:

...
          {
            type = "volume"
            source = "media"
            target = "/media"
            volume_options {
              driver_config {
                name = "local"
                options = {
                  type = "nfs4"
                  o = "addr=192.168.200.10,vers=4.2,noatime"
                  device = "192.168.200.10:/media"
                }
              }
            }
          }
...

error message while submitting:

Error getting job struct: Failed to parse using HCL 2. Use the HCL 1 parser with `nomad run -hcl1`, or address the following issues:
minidlna.job.generated:45,25-26: Missing key/value separator; Expected an equals sign ("=") to mark the beginning of the attribute value.
Error getting job struct: Failed to parse using HCL 2. Use the HCL 1 parser with `nomad run -hcl1`, or address the following issues:
minidlna.job.generated:45,25-26: Missing key/value separator; Expected an equals sign ("=") to mark the beginning of the attribute value.

I can fix this with the -hcl1 option while submitting.
If i add the mentioned equals signs and resulting in the following job snipped:

...
          {
            type = "volume"
            source = "media"
            target = "/media"
            volume_options = {
              driver_config = {
                name = "local"
                options = {
                  type = "nfs4"
                  o = "addr=192.168.200.10,vers=4.2,noatime"
                  device = "192.168.200.10:/media"
                }
              }
            }
          }
...

i can submitt this job without the -hcl1 option, but the job doesn't run with an error:

Failed Validation | 2 errors occurred: * failed to parse config: * Incorrect attribute value type: Inappropriate value for attribute "options": list of map of string required.

So after some try and error i ended with the following job snipped which worked (submitting and running):

...
          {
            type = "volume"
            source = "media"
            target = "/media"
            volume_options = [
              {
                driver_config = [
                  {
                    name = "local"
                    options = [
                      {
                        type = "nfs4"
                        o = "addr=192.168.200.10,vers=4.2,noatime"
                        device = "192.168.200.10:/media"
                      }
                    ]
                  }
                ]
              }
            ]
          }
...

resulting diff:

             type = "volume"
             source = "media"
             target = "/media"
-            volume_options {
-              driver_config {
-                name = "local"
-                options = {
-                  type = "nfs4"
-                  o = "addr=192.168.200.10,vers=4.2,noatime"
-                  device = "192.168.200.10:/media"
-                }
+            volume_options = [
+              {
+                driver_config = [
+                  {
+                    name = "local"
+                    options = [
+                      {
+                        type = "nfs4"
+                        o = "addr=192.168.200.10,vers=4.2,noatime"
+                        device = "192.168.200.10:/media"
+                      }
+                    ]
+                  }
+                ]
               }
-            }
+            ]
           }
         ]

Is this the intended behavior or is it an bug?
The Doku doesn't mentioned the new behavior with hcl2 or the changed syntax.

@notnoop
Copy link
Contributor

notnoop commented Dec 10, 2020

Thanks @MorphBonehunter for reaching out. This is indeed a bug and isn't an intended change. We'll investigate and follow up with a fix soon.

@notnoop notnoop added stage/accepted Confirmed, and intend to work on. No timeline committment though. type/bug and removed stage/needs-investigation labels Dec 10, 2020
notnoop pushed a commit that referenced this issue Dec 15, 2020
Introduce a new more-block friendly syntax for specifying mounts with a new `mount` block type with the target as label:

```hcl
config {
  image = "..."

  mount {
    type = "..."
    target = "target-path"
    volume_options { ... }
  }
}
```

The main benefit here is that by `mount` being a block, it can nest blocks and avoids the compatibility problems noted in https://github.com/hashicorp/nomad/pull/9634/files#diff-2161d829655a3a36ba2d916023e4eec125b9bd22873493c1c2e5e3f7ba92c691R128-R155 .

The intention is for us to promote this `mount` blocks and quietly deprecate the `mounts` type, while still honoring to preserve compatibility as much as we could.

This addresses the issue in #9604 .
schmichael pushed a commit that referenced this issue Dec 16, 2020
Introduce a new more-block friendly syntax for specifying mounts with a new `mount` block type with the target as label:

```hcl
config {
  image = "..."

  mount {
    type = "..."
    target = "target-path"
    volume_options { ... }
  }
}
```

The main benefit here is that by `mount` being a block, it can nest blocks and avoids the compatibility problems noted in https://github.com/hashicorp/nomad/pull/9634/files#diff-2161d829655a3a36ba2d916023e4eec125b9bd22873493c1c2e5e3f7ba92c691R128-R155 .

The intention is for us to promote this `mount` blocks and quietly deprecate the `mounts` type, while still honoring to preserve compatibility as much as we could.

This addresses the issue in #9604 .
@MorphBonehunter
Copy link
Author

MorphBonehunter commented Dec 23, 2020

I've migrate to the new "mount" syntax and it worked like expected (and is much nicer than before i think 😄).
Maybe it's worth to mention this on the Upgrade Guide?
I've seen this was an mentioned "task" in #9635.

backspace pushed a commit that referenced this issue Jan 22, 2021
Introduce a new more-block friendly syntax for specifying mounts with a new `mount` block type with the target as label:

```hcl
config {
  image = "..."

  mount {
    type = "..."
    target = "target-path"
    volume_options { ... }
  }
}
```

The main benefit here is that by `mount` being a block, it can nest blocks and avoids the compatibility problems noted in https://github.com/hashicorp/nomad/pull/9634/files#diff-2161d829655a3a36ba2d916023e4eec125b9bd22873493c1c2e5e3f7ba92c691R128-R155 .

The intention is for us to promote this `mount` blocks and quietly deprecate the `mounts` type, while still honoring to preserve compatibility as much as we could.

This addresses the issue in #9604 .
@MorphBonehunter
Copy link
Author

I think we can close this as the problem was solved long ago 👍

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
stage/accepted Confirmed, and intend to work on. No timeline committment though. theme/hcl type/bug type/question
Projects
None yet
Development

No branches or pull requests

3 participants