-
Notifications
You must be signed in to change notification settings - Fork 2k
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
docker: introduce a new hcl2-friendly mount
syntax
#9635
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few concerns with this approach.
- Block labels can't currently be interpolated, which means until we implement Can't use variables or locals on block labels #9522 this would be limited relative to
mounts.destination
for interpolation. - I'm worried that having a very similar alternative is going to be more confusing than having folks migrate.
- Are there other places we're going to see this problem and does providing an alternative in one place but not others make for an inconsistent UX?
These are reasonable concerns.
My concern, is that confusion of when a block syntax is required vs an assignment syntax is going to remain confusing. But I agree that it's better not to rush a new syntax that we may regret and be beholden to for backward compatibility concern.
I'd note that a generic solution is to exploit our hcl2 parser special casing of task config, how block encodings match array assignments in the underlying representation. The following two block declarations are actually equivalent (inside a task config: #### USING ASSIGNMENT SYNTAX: no nested blocks are allowed
mounts = [
# sample volume mount
{
type = "volume"
target = "/path/in/container"
volume_options = {
no_copy = false
labels = {
foo = "bar"
}
driver_config = {
name = "pxd"
options = {
foo = "bar"
}
}
}
},
# sample tmpfs mount
{
type = "tmpfs"
target = "/path/in/container"
readonly = false
tmpfs_options = {
size = 100000 # size in bytes
}
}
] vs #### USING REPEATED BLOCK DECLARATION SYNTAX: nested blocks are allowed, yay!
mounts {
type = "volume"
target = "/path/in/container"
volume_options {
no_copy = false
labels {
foo = "bar"
}
driver_config {
name = "pxd"
options {
foo = "bar"
}
}
}
}
# sample tmpfs mount
mounts {
type = "tmpfs"
target = "/path/in/container"
readonly = false
tmpfs_options {
size = 100000 # size in bytes
}
} The second syntax is more in line with Nomad's job syntax. The downside is What do you think? |
Oh yeah, that repeated block syntax looks a lot nicer. I'm definitely sold on that if we can avoid having the labels too. |
Introduce a new more-block friendly for specifying mounts: ```hcl config { image = "..." mount { type = "..." target = "target-path" volume_options { ... } } } ``` We introduce this as the current `mounts` require a list of mounts, that `hcl2` doesn't allow to have a map syntax.
e62b70c
to
c135f2e
Compare
Great! I've updated the PR to use the repeated non-labeled block syntax. The test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New form looks much better. A shame it's not perfectly backward compatible, but we knew this was likely to happen. I'm a bit worried about other places we might be missing. devices
seems susceptible but does not have any nested structs (yet?).
Docs to update:
[ci skip]
Will update the docs after #9638 merges. |
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 .
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 .
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
Introduce a new more-block friendly syntax for specifying mounts with a new
mount
block type with the target as label: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 themounts
type, while still honoring to preserve compatibility as much as we could.This addresses the issue in #9604 .