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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shaky plan with empty bind_options block #222

Closed
alexkunin opened this issue Jun 7, 2021 · 0 comments 路 Fixed by #234
Closed

Shaky plan with empty bind_options block #222

alexkunin opened this issue Jun 7, 2021 · 0 comments 路 Fixed by #234
Assignees
Labels
bug Something isn't working r/service Relates to the service resource
Milestone

Comments

@alexkunin
Copy link
Contributor

alexkunin commented Jun 7, 2021

Community Note

  • Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and docker Provider) Version

Terraform v0.15.5
on darwin_amd64
+ provider registry.terraform.io/kreuzwerker/docker v2.12.0

Affected Resource(s)

  • docker_service

Terraform Configuration Files

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "2.12.0"
    }
  }
}

provider "docker" {
  host = "ssh://..."
}

resource "docker_image" "test" {
  name = "nginx:alpine"
}

resource "docker_service" "test" {
  name = "test"
  task_spec {
    container_spec {
      image = docker_image.test.latest

      mounts {
        target    = "/tmp/test"
        type      = "bind"
        read_only = false
        bind_options {}
      }
    }
  }
}

Debug Output

Full output of terraform plan can be found here, and this is the part which demonstrates the problem:

  # docker_service.test will be updated in-place
  ~ resource "docker_service" "test" {
        id   = "ifns8ievwf6sns45psrlocdq5"
        name = "test"



      ~ task_spec {
            # (3 unchanged attributes hidden)

          ~ container_spec {
                # (8 unchanged attributes hidden)



              + mounts {
                  + read_only = false
                  + target    = "/tmp/test"
                  + type      = "bind"

                  + bind_options {}
                }
              - mounts {
                  - read_only = false -> null
                  - target    = "/tmp/test" -> null
                  - type      = "bind" -> null
                }
                # (2 unchanged blocks hidden)
            }



            # (3 unchanged blocks hidden)
        }
        # (2 unchanged blocks hidden)
    }

Expected Behaviour

Running terraform plan and/or terraform apply should not cause any updates.

Actual Behaviour

Service change is planned/performed every time.

Steps to Reproduce

  1. terraform init
  2. terraform apply -auto-approve
  3. terraform plan or terraform apply

Important Factoids

According to docs, block bind_options is optional, and it has the only possible key which is also optional. (BTW there is copy-paste typo in docs, but I'll submit that as separate issue/PR).

But actually the behavior is shaky:

  • not supplying bind_options at all gives stable plan
  • supplying empty bind_options {} leads to a change every time
  • with bind_options { propagation = null } there is a change every time too
  • with bind_options { propagation = "rprivate" } (which is default value according to docs), there are no changes, the plan is stable

Not having empty bind_options {} might be tricky if configuration is generated (e.g. using TF module) since this is not a field like env = { ... } (could set it to null), and not a top-level resource block (could use conditional count = 0). Setting default value is also not an optimal solution as defaults might change over time, or they might be different for other platforms.

So, proposed solution would be treating empty bind_options {} block as if it was not specified at all. Maybe same should be done if it was specified as bind_options { propagation = null } too.

Update: I've mentioned a bug in docs, but apparently it is a bug in doc generator, and @mavogel is already aware and involved.

@mavogel mavogel added bug Something isn't working r/service Relates to the service resource labels Jun 14, 2021
@mavogel mavogel self-assigned this Jun 23, 2021
@mavogel mavogel linked a pull request Jun 23, 2021 that will close this issue
@mavogel mavogel added this to the v2.14.0 milestone Jun 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working r/service Relates to the service resource
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants